From owner-freebsd-hackers Mon Nov 22 20:14:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 1CB6915076 for ; Mon, 22 Nov 1999 20:14:14 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (crossd@a.cs.rpi.edu [128.213.12.1]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA85404; Mon, 22 Nov 1999 23:14:04 -0500 (EST) Message-Id: <199911230414.XAA85404@cs.rpi.edu> To: Alfred Perlstein Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: wacky rpc.lockd idea... In-Reply-To: Message from Alfred Perlstein of "Mon, 22 Nov 1999 16:20:34 PST." Date: Mon, 22 Nov 1999 23:14:03 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. Hmm... I wold think even without having the file "open" a lock would be enough. Seems kinda pointless of a lock if it doesn't protect something as trivial as an rm ;) > How this would break semantics (auto-locking executables over NFS) is > another matter, I would make sure it stays as an option. As long as you make it a shared lock, read-only, I think those are always guaranteed to suceed, and to never affect other locks. Perhaps I am wrong in this. > 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. I agree that nfs_bio should be more tolerant of these types of faults. However a process in the middle of a page-in is not killable, and leaving it stuck in disk-wait is also not a viable option IMO. -- David Cross | email: crossd@cs.rpi.edu Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message