> Our NFS servers for user home directories are on FreeBSD (6.4),
> MacOSX (10.5), Linux (still 2.4 kernel) and Tru64-UNIX boxes; NFS
> clients are mostly Linux (2.6 kernel) and FreeBSD (6.4, 7.0, but
> w/o kernel lockd) systems.
I have seen problems with NFS locking even in completely homogeneous
environments. With a mix like that, I would not trust it as far as
I could throw a Cray :)
> There are periods of several days without problems, but from time
> to time, on one, two, or several (but not all) clients application
> processes which use locking suddenly hang in kernel mode - namely
> firefox, opera, pine.
Lockups are probably the least of your concerns, at least where
pine is involved. Dunno what sort of data firefox and opera are
protecting from race conditions, but I suppose pine is being used
for email. Cases will arise wherein mail mysteriously disappears,
because the client and the delivery agent were both updating the
inbox at the same time. Often there will be no noticeable symptoms,
except for users wondering what happened to that important message
they were supposed to have gotten (and which the MTA log shows was
in fact delivered).
Never export an inbox read/write if reliability of mail delivery is
needed. Use IMAP instead.
> It seems to be no specific operating system problem - all
> combinations of clients and servers are involved.
I suspect the reason NFS locking is so troublesome is that it
presents problems which are fundamentally incomputable. Prior
to restoration of communication, how can any automaton possibly
* a temporary loss of the communication link (but the peer is still
running and the link will eventually be re-established), and
* the peer has crashed, and will eventually reboot?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"