From: Brent Callaghan (Brent.Callaghan@eng.sun.com)
Date: 08/13/98-01:10:07 PM Z
Date: Thu, 13 Aug 1998 11:10:07 -0700 From: Brent.Callaghan@eng.sun.com (Brent Callaghan) Message-Id: <199808131810.LAA02560@terra.eng.sun.com> Subject: Re: Locking questions Hi Craig, > I have a couple of questions about the Strawman locking protocols. > > First, the lock ID is a 64bit quantity, specified totally by the client. > There should probably be some remark that this ID value needs to > include a value unique to the client as well as some value unique within > that client. (I'm assuming that the NFS server doesn't retain any state > about the client that made the call except for this ID value. If the > server retains some state, then it shouldn't simply be a single network > source address, since that address can change for successive calls.) > > If my assumptions are correct, then perhaps the strawman should indicate > some subdivision of the lock ID number space, like whether a client ID > should occupy the most-significant bits of the lock ID and the > within-client value the least-significant bits. Yes, you raise a good point. The lockid is supposed to be unique but the protocol should be more explicit as to how that is to be achieved. The easiest way to achieve this would be to have the client choose a lockid randomly or pseudo-randomly. I think 64 bits is a large enough space that it provides a reasonable assurance that two clients won't collide. If that's not enough then 96 or 128 bits must surely provide an assurance that the chance of collision is disappearingly small. Using the lockid as the sole identifier of the lock absolves the server from the problem of identifying the "client". The client may a thread within a process within a multiprocess environment on a cluster machine. The lock requests may also come from varying network addresses if the client is mobile (perhaps an "agent"), or on a cluster, or is coming through varying proxies. The lockid transcends all of this. > Now, about these lock semantics. Using these lock primitives, there is > no mechanism to implement advisory locking (with no impact on concurrent > reads or writes). I'd guess that the Strawman drafters felt that this > was an advantage, that advisory locking is error-prone. Is this the > idea? Is it worth the novelty of denying I/O requests to Unix clients? The lack of advisory locking is certainly an issue. Of course it would be possible to add an "advisory vs mandatory" flag to the lock requests with the expected semantics, i.e. advisory locks do not deny reads and writes by processes that decline to participate in locking. On the other hand, are advisory locks just a poor cousin to mandatory locks ? Would a process or user doing advisory locking be pleased or disappointed if their lock had a mandatory effect ? The protocol is certainly simpler if there's just one kind of lock. > Much as this mandatory lock model mimics DOS/NT semantics, the DOS/NT > SHARE and DENY modes aren't covered in the Strawman. Wouldn't it make > sense to include that functionality in separate operations that also > work like leases? A SHARE operation could accept share and deny > operation masks, validating them against shares already in place. > SHAREX could extend the SHARE lease, and SHAREU could end a SHARE lease. Yes, this may be the best way to deal with DOS Shares. Model them on the locking primitives but implement them as advisory only and have no interaction with file locking. > The ``10.9. Locking and the new latency'' section mentions that > read-locking can protect cached data on a client, but it's a puzzling > protection. Would a client dare hold a read-lock for longer than > necessary to protect its cache? How could it find out that a writer was > trying to update the data? It seems to me that the server cannot just > unilaterally deny LOCKX requests for a lock if a conflicting lock had > been denied. This model would work OK for if the original lock were > just being held to protect a data cache, but it would seem imprudent if > the original lock were being held because an application had explicitly > obtained a mandatory lock. Should different locks be used for cacheing > from the locks used for application state? Yes, David Robinson has also pointed out this dichotomy: a client that uses a read lock to protect cached data will not be terribly upset if the server denies a LOCKX, but if the lock is to protect a transaction then the client process might be very upset if the lock (assured by the local API) is snatched away with a denied LOCKX. One way to resolve this would be to extend LOCKX to provide a mandatory lock extension with the expectation that the client would use it only for locks imposed explicitly by the application and the non-mandatory extension to be used for cache protection. BTW: I wouldn't expect clients to use cache protection locks for long-term cache protection. It would be reasonable to lock the cache while a file is open by one or more processes then unlock when no process has the file open on the client. More conventional cache validation (with NVERIFY) would be used to validate the cache when the file is first opened. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:08 AM Z CST