Subject: RE: [nfsv4] Parallel open support

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 20 Sep 2006 10:17:28 -0400

Let's deal with CLOSE.  If you are doing CLOSE on a stateid
for which there are locks being gotten or released or such
requests in flight, then whatever happens to you is essentially
your fault.  You are supposed to quiesce before you do the
close.

Now consider LOCK and LOCKU in v4.0.  Both contain a seqid
relative to the lockowner so that there can be only one
request outstanding at a time.  The client gets to decide on
the order and where the order matters he must decide correctly.
If a bad order is chosen, the client shouldn't blame the server
or the protocol.  

In v4.1, the model is somewhat different in that there is no
mandated sequencing and a client can issue requests in parallel
such as a LOCK and LOCKU for overlapping ranges and the result
of that is indeterminate.  It is up to the client to serialize
these if it wants/needs to.  If it doesn't, it gets the results
it gets.

This is not a major departure in protocol structure.  NFS has
always had the ability for the client to issue requests whose
results are indeterminate due to sequencing issues.  Do a 
READ and WRITE in parallel on the same fh.  The READ may get 
the data before the WRITE or fater after or even a mixture 
on some servers.  If the client doesn't like that uncertainty,
then it should serialize things.

I think the relevant fact here for v4.1 is that there are 
no sequence streams (or there are as many as slots) and 
clients which have additional ordering requirement need to
impose them internally.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 11:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [nfsv4] Parallel open support

On Tue, 2006-09-19 at 18:16 -0700, Mike Eisler wrote:

> Yes, but if did result in different open_owners it, as long as the 
> lock_owner is the same, the locks on the file cannot conflict. It is 
> permitted by RFC3530 for the client to produce different open_owners,
> 
>       The state model has added an open_owner4 identifier.  This was
>       done to accommodate Posix based clients and the model they use 
> for
>       file locking.  For Posix clients, an open_owner4 would
correspond
>       to a file descriptor potentially shared amongst a set of 
> processes
>       and the lock_owner4 identifier would correspond to a process
that
>       is locking a file.
> 
> So fd1 shared between a parent and child process must have the same 
> open_owner, and fd2 known only to the child process may have a 
> distinct open_owner.

Stupid, 'cos it is completely impractical. As I have repeatedly said, if
you have more than 1 sequence stream, then the LOCK/LOCKU/CLOSE are not
ordered, and you are allowing the client to screw itself.

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

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

---

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

> If a bad order is chosen, the client shouldn't blame the server

Not according to Mike, as I understand it.

As I understand his description, the locking state apparently is defined
per <filehandle,lockowner> pair. That allows you to associate the
lockowner directly with a process pid.

OTOH, he would like to associate the open_owner directly with a file
descriptor. This analogy implies that a single process can have several
open_owners (and a single open_owner can be shared by several
processes).

The problem is, that sequence ids are set up using a
<filehandle,lockowner,openowner> triplet (via the open_to_lockowner
mechanism). This would mean that your process can, and will, have
several seqid streams per <filehandle,lockowner> provided that it has
more than one openowner (file descriptor) on the same file.

In Mike's scenario, there can therefore be more than one request
outstanding at a time, since LOCK/LOCKU on those different sequence id
streams apparently act on the common <filehandle,lockowner> locking
state, but are completely unordered w.r.t. each other.

> clients which have additional ordering requirement need to

Mike's vision for how lockowners should work is fine in a 4.1 setting,
since sessions provide well-defined only-once semantics that don't rely
on the seqid mechanism.