On Tue, 7 Nov 2006, David Severance wrote:
At the risk of
irritating you further it doesn't help your argument by ignoring the fact
that there is a way to make it work successfully.
There is no "fact" to ignore. NFS is not a suitable back end for IMAP.
The maximum functionality that you can hope to achieve is single-session
access to a limited degree with traditional UNIX mailbox format accessed
over an NFS back end. Most IMAP clients today are not single-session
access.
There ARE cases where even single-session access will fail. The most
common outcome in those cases are lost messages; in other words, a message
is delivered but then vanishes. There are other cases where the mailbox
gets trashed, but it isn't always noticed (see below).
Again I don't refuse to believe you when you talk about NFS, I'm just not
doing the things that would get me in trouble.
Actually, you probably *are* doing those things, but don't realize it.
Non-rigorous empirical observation is a very poor method. A lot of bad
things can go on without being noticed or being put down to other causes.
Dependency upon user complaints is particularly unreliable.
One property of the traditional UNIX format is that it is very difficult
to corrupt the file in such a way that it will not open. Nothing short of
damage to the very first "From " line will do that.
Thus, it is possible for a traditional UNIX format mailbox be thoroughly
trashed, and still be openable. There'll be some trashed messages, and
generally some message duplication. But, since the user can open the
mailbox and most messages are spam anyway, many users won't bother
complaining.
Similarly, in this day and age of spam, it is easy for messages to go
missing and unremarked. User A sends a message to User B, and User B
never sees it. Must be the spam filters or something.
The only reason I got involved
in this thread was to see if I understood the pluses and minuses of, as I see
it, the two approaches to implementation. I would really like to hear from
you in particular on this. You see, I recognize we have reached the limits of
what I can do with NFS.
UW went through all of this:
. My saying "don't use NFS"
. The Powers That Be insisting upon NFS.
. My being accused of "ignoring the fact that NFS can be made to work"
(because The Experts At IBM said it would and they were giving us a
great deal).
. "We're not doing the things that would get us in trouble."
. A growing realization that the system was slow and unreliable.
. IBM giving us additional free hardware to make it faster and more
reliable.
. That additional hardware doing no good at all.
Eventually, UW abandoned NFS for our IMAP servers. This happened over a
decade ago, and we have never looked back. We stayed with SVR4 (AIX) for
considerably longer, but that mistake has been remedied as well.
We still use NFS for file service. NFS is an excellent file service. It
is just wretchedly bad as an IMAP back end (or for that matter as a store
for any distributed multi-access read/write database).
I'd like to offer my users more but it seems like in
order to do that I have to accept a single point of failure model. I had
thought we were quite past the point in time where that was considered an
acceptable model in a large enterprise type environment even if that is a
University.
But NFS *is* a single point of failure!
You may have a dozen IMAP servers, but they are all go to a single NFS
server. Your argument basically presumes that IMAP servers are more
likely to fail than NFS servers. That's a fallacy.
Server reliability is very often a function of how much the server is
being asked to do. A shell-access timesharing system that has FTP, SMTP,
IMAP, etc. servers is much less reliable than a box that has only IMAP and
some mechanism (LMTP or limited SMTP) to deliver mail into it.
Your NFS server may have all sorts of redundancy, but a single physical
action can take it down.
It all ends up as file data in one place. You can have that file data
mirrored in various ways, but that doesn't change the basic point. And
when you have an NFS monolith, then everything is on the monolith.
Take down the monolith, and everything is lost.
Independent, small, dedicated, inexpensive boxes create a more reliable
overall facility that a cluster centered around a monolith.
Unlike the NFS monolith, we have no single point of failure that loses the
entire IMAP service. The worst case scenario is that a small percentage
of the user community is temporarily (a matter of minutes) offline while
we deploy a replacement.
We don't even have all our IMAP servers in the same building; a Ryder
truck packed with fertilizer and diesel fuel won't wipe out our services.
And, of course, we have disaster recovery planning; not just for the Ryder
truck, but for more likely things (e.g., earthquake) destroying one of our
data centers, etc.
This point bears repeating: no single event can take down our entire IMAP
service.
Does everyone just accept
this single point of failure issue without concern? I'm finding it a hard one
to sallow that with 40K users to support.
UW has more than twice as many users. A single monolithic NFS server is a
single point of failure that we do not accept.
UW imapd goes through heroic efforts to keep traditional UNIX format files
from being corrupted when accessed via NFS. Among other things, those
efforts slow down the handling of traditional UNIX format files for
everybody, even those who do not use NFS.
Thank you for making it work if even in a narrow subset. Perhaps there should
be a compile time option to put in / take out NFS code that slows things
down. But that may be more work than it's worth since for performance you
should really use a different mailbox format.
Most of the file management algorithms need to be complete different. I
know, because I had to rewrite them several times to deal with NFS buffer
cache issues.
But that's only for traditional UNIX mailbox format. The other formats,
notably mbx and mix, don't stand a chance of working over NFS.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
