Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Jul 1997 09:32:31 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        lederer@bonn-online.com (Sebastian Lederer)
Cc:        terry@lambert.org, freebsd-hackers@FreeBSD.ORG
Subject:   Re: NFS locking, was: Re: NFS V3 is it stable?
Message-ID:  <199707021632.JAA06741@phaeton.artisoft.com>
In-Reply-To: <33BA0339.167EB0E7@bonn-online.com> from "Sebastian Lederer" at Jul 2, 97 09:28:57 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 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).

Yes.  This is a bad assumption, since the handle is opaque data.
An FS is free to give whatever handle it wants to back for any
given inode.  This includes different handles for two instances
of the same inode.

Consider the case where the file handle is actually a reference to
a "node" in a unioned FS which has been exported.


> 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.

Yes, especially if it overrode other braindamage, or allowed flags
that would override othe brain damage.


> > No.  NFS client locks are not forwarded through a local lockd,

[ ... ]

> 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 nfs_svc system call is a System V -ism.  SunOS 4.1.3, the OS on
which NFS locking was first implemented, and therefore the reference
platform for interoperability testing, does not run a lockd unless
you export FS's for other machines to mount.  The NFS client code
makes the RPC calls directly.

Also note that "lockd is /part/ of the NFS lock manager" and "The
/lock manager/ provides...".  I believe even under SVR4, the lockd
does not make the remote requests, the lock manger does... which is
to say the NFS VFS module in the kernel.



> > 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...

Let me know when you have completed the upgrade.  It may take you
a while.  After that, give me the CVS mirroring time, and I will
try to come as close as possible when cutting the patches.


> 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 will look at it.  Since I've been doing the kernel code for this,
I might be able to use it as a basis for the client.


> 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.

Actually, I believe there is a similar offer for a 2 user Solaris.
I was waiting until I got a second JAZ drive for this, myself.  I
think the SCO offer is SVR3 based (I may be wrong), and the SVR3
lockd code is notoriously flawed.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707021632.JAA06741>