On Fri, 29 Sep 2006, David Severance wrote:
Is MIX any more or less susceptible to problems over NFS than mbox
format?
Neither mix, not mbx, are suitable for use over NFS. Both formats depend
upon locking which NFS does not provide.
I ask because we run an NFS environment off of several current
generation NetApp boxes with no problems for many, many years serving
10's of thousands of users.
Traditional UNIX mailbox format "works" with NFS to a limited degree. The
only locking is provided by the .lock files which are sufficient to
protect against conflicts between MUA and delivery.
However, .lock files do not protect against conflicts between multiple
MUAs opening the same mailbox. When NFS is not involved, the client
library (the basis of Pine, UW imapd and ipop3d, mailutil, etc.) has
locking that will kill the older MUA process.
That mechanism does not work when NFS is involved. Instead, both MUAs
will continue to work with the mailbox until the time comes that one MUA
alters the file, and the other MUA discovers that it is confused where
messages are located and crashes. In other words, the traditional
behavior of UNIX MUAs.
Many IMAP clients routinely spawn multiple sessions to the same mailbox.
For this and other reasons, traditional UNIX mailbox format is not really
suitable for IMAP use even those UW imapd supports it.
Despite warnings about potential NFS problems this
system has worked extremely well and I was wondering if there was
anything that would make MIX more or less susceptible to NFS
difficulties as compared with mbox which we currently use.
When NFS is used, there is no locking. Mix depends upon locks to handle
simultaneous access correctly. Mix and mbx are not suitable for use in an
NFS environment. You'll probably hear the same thing from the Cyrus guys.
NFS is not a real filesystem.
I've given the following religious talk before, but it's worth repeating:
99% of all environments that have IMAP servers access mail via NFS do so
with a mistaken notion that this somehow helps with "the load". IMAP
servers are I/O bound, not CPU bound. Thus, it is better to have run the
IMAP server on the box that has the file bits.
Another problem is the perception that a monolithic mail store is a good
idea. It isn't. It is better to break up the mail store into smaller
mail stores.
At UW, we have a number of IMAP server systems, each dedicated to a
portion of the user space. We have a special DNS zone, tied to our
accounting system, so that mrc.deskmail.washington.edu always points to
mrc's IMAP server system, wherever it may be today. Today, it is a
machine called cg15.u.washington.edu. I neither know, nor care, where it
may be tommorrow as the sysadmins may choose to move me at any time.
It also isolates failure. If one of our IMAP server systems fails, then
only a small fraction of the user community is affected (and we have hot
spares ready to deploy if needed). If the NFS monolith fails, then you
lose everything. Also, our systems are split across different facilities
so a disaster in one facility doesn't take out service for everybody. [Of
course, we do have disaster recovery procedures, albeit non-instantaneous,
for the portions which are taken out]
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
