That would then make me assume that though our IMAP server appears to be working it must be silently working incorrectly, because we are accessing IMAP's data store from NFS. What symptoms would I experience when a flock() lock erroneously succeeds?
If you are lucky, the worst that will happen is that from time to time an IMAP server will crash with the message "Unexpected changes to mailbox"; that is, it will detect what happened and kill itself rather than cause any damage.
If you are unlucky, the mailbox will be corrupted, messages will be lost, etc. If you get a message about "mailbox vulnerable" and talking about 1777 protection, then you are definitely unlucky; and disabling that message will not remedy matters but rather simply disable the warning of your misfortune.
Again - from what I understood, this issue with flock() over NFS has been fixed - besides isn't that what the nfslock daemon is for?
I hope not! Those lock-over-NFS daemons are for fcntl() locking only, and THEY DO NOT WORK WORTH A DAMN! It is a *feature* that flock() does not use those broken daemons.
To me this means that the documentation on file locking is relevant to us???? Although I don't feel that I fully understand the implications.
The jist that you should get is that although there is basic compatibility in locking between all this software, you should use companion software whenever possible.
For example: if you use UW imapd for your IMAP server, you should use UW ipop3d for your POP3 server. If you use Cyrus imapd for your IMAP server, you should use Cyrus pop3d for your POP3 server.
If you mix non-companion softare, such as UW imapd and cucipop, you will have basic compatibility on locking but less compatibility than if you use companion software. To what extent this may cause problems is uncertain. It is not a recommended configuration.
The NFS Server is mirrored and has a seamless failover device.Has your management considered that they have a single point of failure (the NFS server) in their configuration; and that when that point fails your entire facility is dead?
OK, so I cut the wire that goes to your NFS server. Or I run a virus on it that piddles over the filesystem. It's still a single point of failure.
Do you mind if I ask how many users you serve?
6 digits.
When we put IMAP *on* the NFS server (POP and SMTP access the data over NFS and IMAP accesses the data directly from the drive) IMAP begins to perform a degree of magnitude better than we ever expected, however SMTP processes are waiting for IO, and we are unable to get more than a minimum amount of POP and SMTP connections made to those servers, of which only a handful complete and the rest time out.
This should tell you something: don't use NFS.
Lustre is able to mirror data over multiple target nodes and rebuild the data seamlessly if lost. It promises to create paralell connections to different disks on different servers over separate network ports with multiple "middleware" (MetaData) servers constantly redirecting traffic. We're hoping that this would sufficiently divide the labor for I/O.
The more that I hear about Lustre, the more convinced I am that it is unsuitable for IMAP. It's optimizing the wrong things.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
