Thomas Hurst wrote: > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > > Are there any tricks to speed this up, some caching mechanism or > > something. I'm already using ReiserFS and maildir.
> The solutions are: > > 1. Switch to mbox and trade off individual mail modification speed > and corruption resistance for initial opening speed. yum. we use Maildir on our office mailserver so i've just ended up using this. it *is* pretty slow though, particularly on ext2fs. > 2. Use a maildir caching patch to limit scanning of new messages to > operations on a dbm. i've been doing this, and i find that it can definitely make a difference, although since the only large mailboxes i have are ones i don't enter frquently, it often still takes a while to open the mailbox while the cache data is being updated (the actual caching itself seems to take a while sometimes; it took me 13 seconds to initially open a Trash folder i hadn't opened in a while; the second try was only like 1.5 seconds. however unpatched mutt was consistently around 6 seconds). > 3. Make use of the low cost of moving messages from the start of > the maildir to archive old messages. Leave your working folder > as maildir with a maximum of a couple of days mails and keep mbox > archives or so. yup. personally i don't see the need of keeping that many messages around. i prefer to only save messages i find interesting, which means most of my folders have between 20 and 150 messages in them (and my inbox rarely has more than 15). i know a lot of people are the opposite, but i don't understand it. i go through and archive trash folders and such every once in a while (into bzipped tarballs), and other than that, i look something up in the mailing list archives if i can't find it. that's what online archives are for; admittedly it's sometimes easier to search your own, but i don't like keeping thousands upon thousands of extra emails around just in case i might need to use them. i do keep separate inbox trash folders (and separate trash folders for work mailing lists). that way i can archive those for longer than regular list mail, spam, cron related stuff, etc. > 4. Find a filesystem which keeps lots of small files in the same > dir consolidated together with the metainformation it needs to find > them to cut down seeks and small reads. i know one person who put her mail on a separate partition (ffs) and used tunefs to change the average filesize (smaller) and average number of files in a directory (bigger). she also was using soft-updates (which i've heard isn't really the greatest idea for mail, since it's conceivable that you could lose mail)... in any event, she said this increased performance, however i'm not sure if there is any equivalent to tunefs for reiserfs. i have no experience with reiserfs personally, but i have heard that it's pretty slow. one other option would be to try using mutt over IMAP with an IMAP server like courier. i think that might speed things up since there's a lot of caching going on server side. -- Will Yardley input: william < @ hq . newdream . net . >
