svn commit: r192256 - head/sys/fs/nfsserver

[Rick Macklem]

On Wed, 20 May 2009, Doug Rabson wrote:

> Thinking about this for a few more minutes, I think you probably want to 
> allocate a sysid for each client and then for each lock_owner of that client 
> allocate a 'pid'. The value doesn't have to be a process identifier but it 
> does have to allow different lock owners from the same client to be 
> distinguished.
>
Why do they need to be distinguished? The nfsv4 state subsystem handles
all conflicts between them, so they are just "nfsv4 locks".

An nfsv4 lockowner is a ClientID + up to 1024 bytes of opaque name and it
might not persist in the server beyond the point where no locks are
held and the associated OpenOwner no longer has any Opens. After this,
the same lockowner could be "re-incarnated" (ie. create a new state
data structure in the server with the same ClientID + up to 1024 bytes)
when the client chooses to do more locking on it. If a pid is generated
sequentially, this second re-incarnation would end up with a different
pid although it is the same lockowner. (To ensure this doesn't happen,
the server would have to hold onto the lockowner state structure "forever"
and that obviously isn't practical.) Or a pid could be a 32bit checksum
on the ClientID + up to 1024 bytes instead of sequential assignment. In 
that case the re-incarnation would get the same pid, but it wouldn't be
guaranteed to be unique across all different lockowners.

As such, the most an assigned pid could be is a "hint" that the lockowner
is different/same. Is there some benefit to this over "held by nfsv4",
which is what using one <l_sysid, l_pid> tuple gives you?

> You probably also want to record locks in the local lock manager on the 
> client. In NLM, I use a different range of sysids starting at 0x100000 for 
> this. This lets you do lock recovery after a server restart by asking the 
> local lock manager to enumerate locks for the right sysid.
>
The lock state all lives in the nfsv4 client (some associated with a
delegation and assigned locally, the rest tied to an associated Open) with 
the "up to 1024 byte" owner names generated by the client, etc. 
Maintaining the rather complex relationship between Opens (with 
Openowners) and their associated locks is probably the "most interesting"
part of implementing nfsv4. Then you must recover the locks, maintaining
that relationship. (The relationship is established via the 
open_to_lock_owner case of the Lock Op.) The recovery code uses client 
side data structures that reflect the open/lock relationship. The lock
manager wouldn't be able to provide that information and I think there
would be little gained by trying to make the major modifications that
would be required so that it could do so.

> On 20 May 2009, at 09:26, Doug Rabson wrote:
>
>> This is incorrect. A sysid of zero is reserved for local locks on local 
>> filesystems. You need to allocate a sysid when the client is created and it 
>> needs to not conflict with the sysids used by NLM. I suggest adding a 
>> function to nlm_prot_impl.c to return the next available sysid (and bump 
>> the counter).
>> 
Ok, when I looked at the code, l_sysid only seemed to be used when 
F_REMOTE is set, so I didn't realize that l_sysid == 0 was reserved
for local locks. I'll look at what you suggest and send you an nlm
patch for review.

rick