🚀 go-pugleaf

In article <LINDA.92Sep1135545@matisse.uni-paderborn.de> linda@uni-paderborn.de (Linda Floren) writes:

   >>>>> Regarding Re: Frequency of NFS lock problems w/ NFS mounted mail spool; karl@ddsw1.mcs.com (Karl Denninger) adds:

   Karl> It is decidedly NOT a good idea to have more than one machine on an
   Karl> NFS-mounted mail spool writing >inbound< messages to a user's mailbox.  
   Karl> The various rpc.lockd bugs will bite you if you try this, and Sun has one of
   Karl> the worst records in this area.  The results are hung sendmail processes and
   Karl> mail that never gets delivered.

   We have a network of more than a hundred Sun4, which all mount the
   mail-directory read-write and do local mail-delivery without
   forwarding to the server ( it would most likely break down if they
   did), and we never had serious problems  with this policy.

We have over 350 client workstations (half Suns, half IBMs) mounting a
single mail directory (from a Sun) read-write, and all of them forward
mail to the server for local delivery.  This machine is also used as a
forwarding machine for mail that goes off campus.  It has not broken
down yet (but we have been seeing some high loads lately).

We have definitely seen locking problems between IBM RS6000 NFS
clients and our Sun4 NFS server.  We have received patched rpc.lockd,
and a new kernel with the NFS jumbo patch, but still we have been
having problems with a user on an IBM NFS client typing "q" to get out
of mail, and the process never returns.  Killing and restarting
rpc.lockd sometimes works to free up these processes that are waiting
for locks from the server, but something only a fastboot of the server
will fix it.  It had been working fine for several months (the "q" bug
had disappeared), so we are not sure why it has come up again now.

I will say that we have doing this for several years (since 1987) with a
network of Suns, and we never had this problem until we added IBM
RS6000 NFS clients into the mix.  It still has been a relatively
stable mail architecture for quite a few machines.

Now, however, in the face of such high loads, and the number of client
workstations increasing, we are working on moving to a solution based
on POP, which we hope will allow us to split the load across two or
more server machines (you can't split one directory across two NFS
servers easily).

If you want more info, send me email.
--
Jim Ault, ITS Systems Programmer, aultj@rpi.edu    <><