Carlos E. R. said the following on 08/26/2013 10:54 AM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-26 a las 15:17 +0200, Hans Witvliet escribió:
From: Carlos E. R. <>
I find Maildir inefficient in terms of perfomance - try doing a full text search on a 12000 mails folder (as the one for this list in this machine).
-----Original Message-----
Really? I am on the brink on migrating from mbox towards Maildir because of efficiency...
I was expecting the opposite from what you write.... If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient. Specially when dealing with large (sub-)folders
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it.
I fail to understand why you would want to modify mail messages once they have been stored. I can understand the modification of the headers as they pass though relays, though spam detectors and the like, but once they hit storage .... why? Do you really want to modify what people have said? I don't understand that.
Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
Same here, but make that much longer. The 'problem' of adding incoming to a mailbox while reading it is not new, it dates back to the late 70s. Concurrent access for read has never been a problem with UNIX; concurrent access for write is a logical problem not confined to UNIX. But the mbox format has used sentinel flags and all mail appreciations seem to obey that simple protocol. In absolute terms appending to a file isn't going to upset another process that is simply reading from the file. In reality, the MUA will 'see' (or be notified) that the file size has increased and re-scan for new headers. How efficiently it does that depends on whether or not you allow the MUA to modify the other mail messages. One reason to use Dovecot and IMAP is that the MUA - Thunderbird, KDE-Mail, whatever - relies on Dovecot to tell it what is going on. Dovecot maintains metadata about the mail box. It can modify the metadata DB without having to modify the mbox itself. It keeps indexes on the mbox and they are 'cleaner' than the MUA/thunderbird (etc) might. q.v. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org