OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Scalability metrics?
From: Liviu Daia (Liviu.Daiaimar.ro)
Date: Fri Feb 11 2000 - 14:33:23 CST

On 11 February 2000, Brad Knowles <blkskynet.be> wrote:
> At 5:42 PM +0200 2000/2/11, Liviu Daia wrote:
>
> > I believe you are confusing Maildir with MH. With Maildir the
> > content of the messages doesn't change once delivered, so you only
> > have to write them once.
>
> Create them once, write them one, read them once, delete them
> once. This is the normal chain of events when dealing with users
> reading their mail and downloading it via POP3. If the number of
> times you write the message is equal to the number of times you read
> it, then your write:read ratio is 50:50.

    True, but this is still much better than copying the whole mailbox
to update the "Status:" flag or to delete a message from the beginning
of the folder.

> Only mail that gets left on the server needs to have the X-UIDL
> header put on it, but of course then this requires an extra write,
> which Maildir doesn't appear to be able to support.

    I didn't check that, but I wouldn't be surprised if POP servers that
support maildir would store the UIDL in the filename, just like the
flags. The maildir format allows this, at least in theory.

> > The only operation that _may_ be slow
> > with Maildir folders is reading large directories and opening
> > thousands of files --- but this is not a problem on most decently
> > recent filesystems.
>
> You haven't read the paper I presented at SANE '98, have you?

    I have to admit I haven't.

> Item number one on the hit parade is ensuring that your
> /var/spool/mqueue directories do not get too big as a result from
> holding too many files. Once you go over about 10k files in a
> directory, you're dead meat. I've found this to be true on every
> single type of filesystem I've ever looked at.
>
> Why do you think we talk about hashing subdirectories with
> respect to mqueues, or hashing directories for user mailboxes?

    Well, this is a typical situation when some people would advocate
using the (in)famous ext2. :-)

> > No. As Bennett Todd pointed out, the filenames in maildir are
> > unique. The only program that _might_ need locking over maildir is
> > a monolithic MTA when writing creating files in "tmp/", because it
> > might choose the same name twice.
>
> Now you're adding even more synchronous meta-data operations.
> You've got them all over the place (perhaps with locking) in your tmp/
> directory, and then you've got them all over again when you go to
> write the files in the actual mailbox.

    That's how a message is supposed to be delivered to a Maildir
folder: it's first written to "tmp/", then moved to "cur/".

[...]
> > But this can be avoided by careful
> > design, and it's certainly not a problem for distributed MTAs like
> > Postfix and Qmail. You definitely don't need locking in MUAs.
>
> MTAs don't do local delivery. You know this -- you've been
> around on the postfix and mutt mailing lists for years. You know that
> this is the job of the LDA (Local Delivery Agent), sometimes referred
> to as the MDA (Message Delivery Agent).

    That's the easy case: unlike sendmail, a single Procmail process
has to deliver only a small number of messages, typically one. It can
generate filenames like

        time.pid.count.hostname

where "count" is the count of messages the process has delivered so far.

[...]
> This is doubly true for those cases where you write one copy of
> the message into each users mailbox -- one 16MB message comes in for
> 250 recipients equals 4GB of data that has to be written out. Do this
> enough, and you can bring any mailserver in the world to it's knees,
> regardless of everything else that may have been done to it to try to
> make it the fastest machine in the Universe.
>
> All current LDAs I know of suffer from this problem, and since
> the average number of recipients per mail message these days is
> something like 2.3, all LDAs I know of do (on average) at least 2.3
> times as much writing as they need to, which is precisely the worst
> possible thing you can do with a solution that depends on the NFS
> protocol and its inherent limitations.

    Agreed.

> > There are also a few POP and IMAP servers that support Maildir
> > --- and those that doesn't can be easily hacked to support it. Not
> > sure what mailers apart from Mutt support Maildir though.
>
> Still gotta handle those X-UIDL headers. Oops, more synchronous
> meta-data updates....

    Well, a rename is usually not worse than an unlink. :-)

On 11 February 2000, Brad Knowles <blkskynet.be> wrote:
> At 6:03 PM +0200 2000/2/11, Liviu Daia wrote:
>
> > Examples of operations that are not robust with the scheme
> > described by Bennett?
>
> The reason mkstemp() exists is to ensure that the temporary
> files are created with relatively secure (and unlikely to be guessed)
> names, which helps prevent people from exploiting race conditions
> to fill up spools, cause your program to over-write binaries that
> shouldn't, etc....
>
> If you create temporary files and you don't use mkstemp() and
> you don't emulate what mkstemp() does, then by definition, you are
> not creating them securely, and are inviting denial-of-service races,
> etc....

    All true, but how does mkstemp() improve the maildir scheme
described by Bennett? The file created in "tmp/" is the final message,
with the final name. If somebody else can create files in "tmp/" (the
one in the Maildir folder, as opposed to things like "/tmp/") you have
bigger problems than that.

    Regards,

    Liviu Daia 

-- 
Dr. Liviu Daia               e-mail:   Liviu.Daiaimar.ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc