Date: Wed, 02 Jul 1997 09:28:57 +0200 From: Sebastian Lederer <lederer@bonn-online.com> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NFS locking, was: Re: NFS V3 is it stable? Message-ID: <33BA0339.167EB0E7@bonn-online.com> References: <199707012024.NAA27875@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> No. The rpc.lockd could not convert a handle into an fd, and
> subsequently close the fd, until all fd's for that file had been
> closed by all clients.
>
> In general, you want to:
>
> 1) Convert handle to fd
> 2) fstat( fd, ...)
> 3) Compare st_ino and st_dev to see if it's already open
> 4) If it is, add a reference count to the already open
> struct and close the new fd
>
> Step #4 destroys all locks with the new POSIX close semantics.
>
So you still have to keep a list of all active locks (with the
corresponding file handles), and if you encounter a filehandle
which is already on the list, there will be already am open fd for it,
and you don't do the conversion again. No need to close a fd.
The only assumption I am making about the file handle is that it
uniquely identifies a file on the server (and that it can be
converted into an open file,of course).
That F_NONPOSIX fnctl would still make things easier, though.
In fact, it might be extremely useful for all sorts of other things,
I presume.
>
> No. NFS client locks are not forwarded through a local lockd,
> they are reissued as a result of an rpc.statd server notification.
> If the client crashes, the lock state on the server is destroyed.
> If the server crashes, the clients have an idea of the lock state
> at the time of the crash, and it must be restored.
Well, at least the Sun manual page for lockd says :
[...]
DESCRIPTION
lockd is part of the NFS lock manager, which supports record
locking operations on NFS files. See fcntl(2) and
lockf(3C). The lock manager provides two functions:
o it forwards fcntl(2) locking requests for NFS
mounted file systems to the lock manager on the
NFS server
o it generates local file locking operations in
response to requests forwarded from lock managers
running on NFS client machines.
[...]
I believe in SunOS there is an extension to the nfssys (=nfs_svc in BSD)
system call, using the LM_SVC flag, for this purpose.
>
> The testing in this case is collateral bugs in the namei() code
> changes, which I didn't seperate from the rpc.lockd changes. If
> I can resolve the namei() leaks, Doug will commit the code to the
> FreeBSD source repository, and it will show up on the next CVSup.
>
> Are you running -current? I can probably make a set of diffs against
> a -current source treee this coming weekend (sorry, that's the fastest
> I can get to it; I'm currently job-hunting).
>
Weekend would be fine. However, I need to upgrade to -current first, my
system is a rather out-of-date 2.2-SNAP. I am still looking for someone
in the vincinity who can put me -current on a tape...
>
> One problem here: FreeBSD does not have NFS client locking code.
> Andrew (the guy who wrote the rpc.lockd) has the ISO standard,
> and is probably a good reference on that. Without a working
> client, you won't be able to test the server.
In the rpc.lockd source directory is a test program that issues fake rpc
locking calls. I've already used it for a little testing.
I could also probably get the free version of SCO UNIX and install it on
one of my boxes. IF SCO UNIX actually does nfs locking, that could be
used for "real life" testing.
The only commercial unix for PCs that I have used myself was
NEXTSTEP 3.2, a few years ago.
And what would you say? It didn't support nfs locking...
Best regards,
Sebastian Lederer
lederer@bonn-online.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33BA0339.167EB0E7>