> 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: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
