Carlos E. R. wrote:
Yes, maildir is slower on some operations, like searches, or anything that requiries reading or writing a whole folder. On the other hand, it is faster at deleting emails, or adding them. Specially deleting an email: in mbox, it means copying the file, and skipping one chunk - or marking some chunks as deleted, and do the actual deletion when the folder is compacted (in thunderbird you do this operation explictly; if you don't, folders grow huge).
You *can* do them explicitly ... or you can set to happen automatically when it will save more than "xx"%. Also an index is sometimes stored in the first message that remains fixed in size and allows for marking messages deleted w/o rewriting the whole mess. Another issue I worry about on files -- ACL's. Linux doesn't do ACL's as well as NTFS. Anything with a default ACL, creates an extra data segment to access if the ACL doesn't fit in the inode (which is likely for any but the simplest of ACLs).
Then mbox is faster in normal operation (reading, browsing), it is more compact. But a file corruption could destroy the whole folder (never happened to me). However, being a plain text file, it can be probably reconstructed. On maildir, a file corruption damages a single email.
Not relevant. I have daily backups and snapshots (both -- serving different needs).
Then there are more advanced, newer formats: for instance, you can combine both methods, and have a bunch of posts in the same file up to some acceptable limit, and then switch to another file. For instance, Pine and uw-imap has one such format, called "mix" (http://en.wikipedia.org/wiki/MIX_%28Email%29). And dovecot has "mdbox" (I believe MIX is better).
---- Yeah, I could see some use for that in some cases, but on my system, optimal io-xfer unit is calced to be 12*64k or 768k, but I also know that I get my fastest disk-io if I do r/w of 32-64MB in 1 call. My fastest Network IO is close to that... about 8-16MB. Using 8MB iosizes: --- R:512+0 records in 512+0 records out 4294967296 bytes (4.0GB) copied, 6.27631 s, 652.6MB/s W:512+0 records in 512+0 records out 4294967296 bytes (4.0GB) copied, 6.29395 s, 650.8MB/s -------------- Not always that fast, but that's ball park top speed for sequential I/O. disk max sequential is about 2x that. So I know with great certainty that I can read and write an entire mbox-file in less time than it would take just read a fraction of them if they were in separate files.
Ah, but you forget the huge number of inodes used :-p
--- Not when each has an ACL on them as well...I tried to make sure that on my new disk, I created inodes at 256 bytes instead of the default 128 bytes so most of my ACL's will fit in the inode. Also given the minimum 4096-byte phys-i/o size using smaller files doesn't make much sense. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org