Subject: RE: [nfsv4] Parallel open support

From: [email-masked]
Date: Wed, 20 Sep 2006 11:03:20 -0400 (EDT)

> So consider the case where you have 2 open_owners, O1 and O2. They are
> both using the same lock_owner string.
> 
> Do the two open_to_lockowner calls create 2 different sequence id
> streams on your server?
Yes. It creates two lock_stateids with separate sequence id streams that
both happen to reference the same lock_owner string, which is what is used to
check for lock conflicts.

>  - if not, how do you ensure that LOCK/LOCKU is ordered w.r.t. CLOSE on
> either O1 or O2?
XXX - Doesn't apply to my server, but see comments below w.r.t. my client.

>  - if, OTOH, it does, how do you ensure that LOCK/LOCKU from stream1 is
> ordered w.r.t. LOCK/LOCKU from stream2?
It doesn't and why should it be expected to? A client has to serialize
whatever it needs serialized. (Again, see below.)

What my client does...
It is a Posix client and maps posix process->lock/open_owner string. As such,
use of an owner string is serialized automagically (it is one serial
execution stream in the client). (If a client uses some other granularity for
lock/open_owner strings, that client will have to serialize Ops on them
whenever necessary, in order to produce correct semantics.)

Because of quirks in the various BSDen's buffer cache code, my client delays
doing CLOSE Ops against the server until the process that did the close syscall
exits. A similar technique might be useful for clients that use more
open_owners, to deal with XXX above. (For example, if a client used
separate open_owners per thread, it could wait until all threads complete
before issuing the CLOSE to the server.) To me, choosing open_owner
granularity is one of the critical decisions in a client writer's
implementation.

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 20 Sep 2006 11:45:57 -0400

> whenever necessary, in order to produce correct semantics.)

So basically, your client sets up a single lockowner/open_owner
association, just like the rest of us do.

So my question stands: what is the point of pretending that locking
state is independent of the open_owner?