bug-mailutils
[Top][All Lists]
Advanced

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

Re: mailutils


From: xystrus
Subject: Re: mailutils
Date: Mon, 11 Mar 2002 22:49:02 -0500
User-agent: Mutt/1.3.27i

On Mon, Mar 11, 2002 at 11:49:09PM +0000, Nic Ferrier wrote:
> xystrus <address@hidden> writes:
> 
> > Well, we discussed this at length on the mutt users list. 
> > Maildir is not without its own problems...  It takes 
> > substantially longer to open and index a Maildir/MH folder 
> > than it does to do the same for a MBOX folder.  
> 
> This is an interesting paper about maildir:
> 
> http://www.courier-mta.org/mbox-vs-maildir/
> 
> I happen to agree with it, but it's interesting whatever your
> viewpoint.

I'll have a look at it when I have a chance... Thanks.

> > > Appending mail is easy, but how about to 
> > > remove message 501 and 60 in a mailbox that 
> > > contains 2000 msgs.  
> >  
> > IIRC from reviewing IMAP4 before, it doesn't allow for this... 
> 
> Yes it does.

No sorry, I guess I wasn't clear.  My sentence above was tied to
what follows.  I'm aware that IMAP allows for deleting random
messages from a folder. :)

> > but what I had in mind for this is to expunge only on mailbox 
> > close, and have the server fork a backround process to do this 
> > so that the user can continue to deal with mail in a different 
> > folder.  
> 
> The trouble with that is that it's not what the IMAP spec says should
> happen and it's not what the user expects either. The user expects
> expunge to be done when they ask for it.

Right.

> > > What happen when something goes wrong? 
> > > Say you ran out of disk space? or Quotas? 
> >  
> > How does using Maildir help these problems?  I think they  
> > actually make it *worse*, as each message now takes up at  
> > least one full disk block, no matter how much data is in it. 
> > The exception is if you're using a filesystem like ReiserFS 
> > which is designed to deal with this by packing data from 
> > multiple files into one disk block... 
> 
> But you can't split a single file across multiple discs

Yes, you can, if you use the LVM.  You can even add disks and 
resize a filesystem without destroying the data with resize2fs.
Most Linux systems don't come with the LVM tools (yet), but they're
out there.

Linux, BTW, is not the only *nix with this feature.  HP-UX has it,
and I believe Solaris has something similar.  From looking at the
Howto, the Linux LVM appears to be modeled after HP's.

> You do seem to have missed the biggest scaling problem with
> maildir. The biggest problem is that inodes tend to run out on you
> with conventional file systems.

Actually I didn't.  You snipped that part out.

> I was the architecht for one of the big european free email systems,
> we started out using maildir for imap but it quickly became apparent
> that we wouldn't be able to do it efficiently because the file usage
> of mail is so high (lot's of small messages). We switched to mbox.

Hmm... one of the other IMAP servers does actually use Maildir...
I think it's Cyrus but I'm not sure now.  I can't really speak to
the performance as I haven't used it.  However, though IIRC it's not
GPL'd, the code is available for review...

> If I were doing it now I'd probably use ReiserFS on Linux, I'm
> planning to try that for a new mail service I'm setting up.

Some people on mutt-users tried using Maildir folders with ReiserFS,
and they said the performance was horrible.  I'll be curious if
you do to hear what the performance is like.  I'm not entirely
convinced that mutt's problems isn't with its implementation, but
I haven't looked at the code, so I really have no idea. :)

> The big problem with imap and mbox of course is locking. You might
> think that isn't a problem because the imap server is a closed
> system, but it isn't quite, not if it implements shared
> folders. Without shared folders then the locking problem almost goes
> away.

Well, you still have to worry about the MDA... 

Xy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]