Re: [Evolution] expunge speed



On 19 Aug 2001 22:47:09 +0200, Alexander Skwar wrote:
So sprach »Ron Guerin« am 2001-08-19 um 16:03:36 -0400 :
mail in.  So I second your question.  WHY mbox?

But then again - why not?  What's the problem with mbox?

There are several - not the least of which is linear access.  Another
(for instance) is that any line that begins with From must be escaped,
lest the mbox parsing code think it's the start of a new message - each
MUA may do this escaping differently - so mboxes aren't *really*
portable (I've gone through migrating mboxes from elm, to pine, to mutt,
to netscape, and to Evo - so I'm speaking from experience here).

It's a pretty darn silly format, actually - but at least it's fairly
standard.  mh is better - in most respects.  It suffers from two things:
1. there's a sequence file which must be locked before adding messages
to the mailbox (though the lock need not be held during delivery) - this
makes delivery inefficient (though not as inefficient as mbox, in which
the entire file must remain locked during delivery).  2. for mailboxes
with large numbers of messages, you start to trip over the fact that
un*x file systems aren't typically tuned for handling directories with
large numbers of entries.  I did some performance analysis on this a few
years ago in a former life - and the curve is linear (bad).

maildir fixes the locking problem with a "smart" naming scheme - but it
can't solve the directory structure problem.  

Some file systems (like veritas, for example) can be tuned specifically
to expect/handle directories with large numbers of small files.  I
haven't looked at any of the current gen filesystems under linux (ext3,
reiserfs, etc.) to see if they do better in this regard.

-- 
   Dan Berger [dberger ix netcom com]
   http://home.ix.netcom.com/~dberger
   Nolite te bastardes carborundorum

   "We are what we repeatedly do.  Excellence, then, is not an act, 
    but a habit."
                                  -- Aristotle

    A982 E6B1 CB2F 7A49  843A 9297 DA73 4371  1F54 8D0C





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]