-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-02-14 at 14:13 +0100, Sandy Drobic wrote: (I forgot to reply to this one, I had fever)
Carlos E. R. wrote:
On Friday, 2009-02-13 at 20:09 +0100, Sandy Drobic wrote:
Yes, so do I, fetchmail, postfix, procmail. But that doesn't mean I have to use maildir. I will not while it doesn't become a standard for all programs. I have read some very strong things agains maildir from some developpers...
Care to tell what kind of problems in what context were caused by maildir?
Just ask dev Mark Crispin what he thinks about maildir... in the context of MUAs, specially, not servers. I have links to the alpine-alpha mail list, where he has been quite explicit, but they require password.
For example: inode waste, in the count of millions. Slow text search, unless you use some database indexing, like beagle. It does not really support concurrency, like one client reading one email and another different client erasing that same email. That there is no standard, and each client or server does its own interpretation. Courier, for instance, uses something like maildir, but not actually maildir.
Granted, it does use more space to store mails in separate files than in one big inbox, this will also slow down search operations since it takes a lot more I/O to scan lots of small files compared to one big file.
Though I challenge you to give me one real life example where one user/program is reading a mail and another one is deleting the same mail without it being a misconfiguration. (^-^)
It wasn't my claim, but his :-) However, I do just that, though I have to be careful not to open the same folder on two programs. I read most of my email with Alpine, but I have to read, lets say business mails, that come in html, with Thunderbird, so I can end with both clients opened - although I usually close one. Another example: I fetch mail from remote servers, like gmail, via imap (fetchmail). This happens in the background. At the same time, I may open the browser to get into gmail and clear the spam. While I'm there, fetchmail may trigger and do a download - and it works fine. However, gmail does not actually delete email.
Especially the issue of concurrency is exactly why maildir is superior to mbox. Try to have ten applications submit mails to the mailbox at the same time. With mbox you will have to serialize it and lock/unlock the mbox files. It has a severe performance drop and is known to cause lots of problems when separate applications are supposed to access mails from the mbox file.
That's understandable. The solution would be an "engine" like a database that would receive and process read and write process to the mail storage. I suppose that if you have an imap local delivery it does something of the kind. The wu-imap server I think uses mbox for storage, I think; I wonder how it behaves under a big load.
You will find a lot of woe reports in the postfix-users mailing list, where users reported performance problems, when the files got big and lots of mails hat to be delivered to the mbox files. The result was delayed delivery due to frequent timeouts on delivery when the new mail could not be added to the mbox file in time.
Supposedly procmail would move the mail to the user local folders before that.
Another problem that often occured was mbox files on nfs storage. The locking was often problematic.
No wonder, nfs and locking is problematic. In fact, IMO, the entire locking issue in Linux is problematic, because there have been several different locking methods: voluntary locking flag files (which name has to be specified), kernel mandatory lock, whatever. In the procmail man page there are references about how to achieve that locking - if the locking mechanism were well defined since ages, this would be clear cut and a non-issue. I remember reading in the msdos programmer's manual the locking methods available. You could lock an entire file, a region, for read, for write, in several combinations. When I cam to Linux and read that procmail page, I was... quite surprised.
The issue with an imap server not using maildir you mentioned is probably Cyrus imap, not Courier. Courier does use maildir while Cyrus uses its own proprietary storage format, even if the mails are stored in single files.
At this point I haven't even started on the problem of acls on shared mailboxes and how they are supposed to work on a single big file.
Buff!
I am, of course, interested in the client side. What an imap server uses internally, does not matter. And the problem is that not all mail client use the same format of maildir folders, if they use any at all. The two clients I use most, ie, Alpine and Thunderbird, do not support maildir.
True, though I consider is little loss. It is easier and more in the spirit of linux to use programs that do their job well and not to have a multipurpose do-it-all program with many features and an equal collection of bugs and incompatibilities.
So I someone uses email intensively it does make sense to let an imap server handle mailstorage and simply use a client that works via imap. That way you can have your choice of clients without having to worry about mailstorage format or migrating all your stored mails to another format just to test a new client.
Mmm... Yes, I know of that method, and I would possible use it of "others", not for me. I'm happy with my setup ;-)
It's fine to use mbox for smaller and few mailboxes but it will simply not scale.
I don't need it to scale :-)
By the way, does anyone know if the problematic setup with the 2 GB mbox files was a 64bit system? I wonder if it was a 32bit limitation of the program and if it could be avoided on a 64 bit system.
Good question. It maybe that the functions to access a text file position is a longint, which is 2GiB in 32 bits. I know that is the situation in dos/win (for fat files at least); I do not know about Linux. But if the same function calls use 64 bit sized variables, automatically the 2GiB limit would be broken. Did I mention the "mix" format for mail storage here? It's neither one file per message nor one for all. Googling for it I found some references that wu-imap might be using it. And also I found confirmation about the 2GiB limit: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478545 ] The report is correct. The c-client library makes no attempt to use the ] 64bit system calls; and thus flat files are limited to 2GB. ] ] The recommended solution for mailboxes with aggregate size greater than ] 2GB is to use mix format instead of a flat file format. Even if ] c-client were updated to use the 64bit system calls, flat files ] (especially in traditional UNIX format) do not perform well at multi-GB ] sizes. ] ] If there is some compelling reason offered, I will consider 64bit ] support. However, as of right now, I am highly skeptical that the ] benefit would be worth the effort, especially since there is a superior ] solution for large mailboxes available now ("superior" since it will ] always work better than a large flat file). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmcnqcACgkQtTMYHG2NR9X/xgCdFPS14b6LSiLAE34HTUkZ6pao THsAn0Q8aH+8vD+Sfr9u6fQPzlXpYUq8 =71rm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org