> 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 distinguish between * 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? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
