On Thu, 28 Jul 2005, Ken Lyons wrote: >We have have a 3+ TB NFS volume where all the email resides. >Each message is stored indepentent of who it was for. >(a database knows all the headers, to's, from, etc). >But in the end it is just a single BODY as a file.
If performance and reliability is important, then you must remove the NFS mount and store the emails physically on disk. NFS is unreliable in its very nature, as there is no guarantee that emails are committed to disk. If you store emails on an NFS mount and your machines crash, then email data will certainly be lost. Also performancewise, NFS is a killer. The load on your system will be much higher than with a physical volume. If saving space is important, then of course, symlinking emails will do some good for you. But it's much better to do what the huge email stores do, and use a file system that eliminates duplicates for you. If you want to use the accessor, or IMAP server, to work with symlinks and so on, then you will be breaking important features in the mailbox specification that directly affect reliability. If I was to do something like what you are describing, then I'd define a specialized mailbox format that stores IDs only, with message bodies stored in a shared collection. Then I'd write a backend for the mailstore accessors that allowed them to deal with this format.. In any case, if you start messing with message contents after they have been delivered to a Maildir mailbox (or any other mailbox), then IMAP clients are at risk to go haywire... :-) Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
