Date: Mon, 22 Nov 1999 16:20:34 -0800 (PST) From: Alfred Perlstein <bright@wintelcom.net> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: wacky rpc.lockd idea... Message-ID: <Pine.BSF.4.21.9911221615561.4557-100000@fw.wintelcom.net> In-Reply-To: <199911222326.SAA79947@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Nov 1999, David E. Cross wrote: > I've noticed about 99% of the panics on our machines are the result of NFS, > more often than not it is the result of a backing store file being blown > away underneath the client. ie. person editing a file on one machine, > compiling and running on a second, then removing the binary on the first > machine. If we had a working lock manager could we not have the kernel open > a shared lock on anything it had in backing store, would that not assure that > files didn't go poof in the night? That's really up to the server lockd/nfsd implementation, but considering that more likely than not the server's lockd will have an open reference to the file until the lock is gone the answer is probably yes. How this would break semantics (auto-locking executables over NFS) is another matter, I would make sure it stays as an option. Another issue is that it's possible that an in kernel implementation of lockd may not follow those semantics so that even if locks are held on the executeable, it may still disapear. It would most certainly be broken behaviour, but I think NFS owns the arena on broken behavour. :) I think that nfs_bio ought to handle the loss of backing store a bit more gracefully, kill -9 wouldn't be unreasonable in such circumstances. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9911221615561.4557-100000>