Date: Wed, 02 Jul 1997 22:42:04 +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: <33BABD1C.41C67EA6@bonn-online.com> References: <199707021632.JAA06741@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > 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. So if we didn't have the F_NONPOSIX fcntl we would only be able to support locking on exported ufs filesystems, nothing else. That would still seem to be quite useful. > 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. But then the kernel on the nfs client would need to act as an rpc server, since the replies from the server's lockd are sent explicitly to the client's nlockmgr rpc service as seperate rpc calls. The rpc.lockd skeleton from Andrew Gordon does the replies this way, I've already checked that. You can simply start the rpc.lockd and use the "test" program to make a fake locking rpc to localhost, and the reply will not go to the test program, but to the lockd itself. Another problem would be that the nlockmgr service port is dynamically allocated, unlike the nfs service port. You could probably specify the nlockmgr port as a mount option, but what if the server reboots and the port number changes? The kernel would have to do portmapper lookups? > > 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. You're right, the free SCO Version is SVR3 based. And you can bet that its lockd code is flawed (one could of course consider SVR3 itself as a flaw). Solaris would surely be preferable, but the current price list shows Solaris 2.5.1 for x86 as about 5000 DM (about 2700 US-$). As soon as I see any special offer there I will probably get it. Best regard, Sebastian Lederer -- Sebastian Lederer lederer@bonn-online.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33BABD1C.41C67EA6>