Subject: RE: [nfsv4] parallel opens in NFSv4.1 ?

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 21 Aug 2006 15:53:17 -0400

> It would likely ease the client implementation if it could count on
the 
> server returning a different stateid (seqid++) at each state changing
> operation.  Is there interest in enforcing this stateid behavior so
> the client's can have multiple OPENs in flight?

I don't see how this helps with the case of multiple OPENs in 
flight (although it might help the case of open and close, see
below).   If the server returns the same core part of the stateid 
(the stateid minus the seqid), then I can't see the extra value 
for the client in knowing which order they happened in.
Generally if clients care about the order things happen in, they
need to control that order.  It is very rare that the client is OK
with either order but needs to only to know which order and that 
doesn't seem to be the case here.

Let's suppose one thread does an open for read and another thread
does a parallel open for write for the same openowner and the same
file.  The opener-for-read can do reads and soon as it gets the 
stateid back.  The opener-for-write can do writes as soon as it
gets its stateid back.  Someone who needs to do both needs to 
wait for both opens to return, but knowing which order they were 
done in doesn't help the client, as far as I can see.

Now consider the case which you try to extend the parallelism to
opens and closes.  In this case if I do a close and an open
(on what turns out to be the same file) then I have an ordering
problem.  If the close happens first, then the open is treated
as a new open an everything is likely to be the way I want it.
On the other hand if the open happens first, then close is going
to close the open just done (along with all the opens for that
file-openowner pair) and the client is likely not to be happy.
Here the client is going to want a particular order and the 
problem is that in the presence of hard links he may not be able
to enforce it since he only finds out that this is the same file
when it is too late, i.e. when his open is destroyed by the 
parallel close.

I think there are two ways around this.  The first is to use the
seqid and then have server either reject or limit the scope of
a close with out-of-data seqid.  There is some complexity in here
is specifying what the server is required to save/recognize as
far as old state/seqid pairs but this might be workable.

Another approach is to simply prevent the unanticipated open merge
and then make synchronization of parallel opens and closes (or 
downgrades) the responsibility of the client.  That is the spec
should say that merger of opens and sharing of stateids for opens
is in terms of the directory/filename pair, and not the target
file.  If this were the case, the client could never be blindsided
by a hard link.  His close would only apply to the opens for
the initial link and any new open in parallel with the close 
would get its own stateid since it is for a new directory/filename
pair (and if it were the same pair the client would be obligated 
to wait for the close).

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 3:16 PM
To: [email-masked]
Subject: Re: [nfsv4] parallel opens in NFSv4.1 ?

On Tue, Trond Myklebust wrote:
> On Tue, 2006-08-15 at 10:22 -0700, eric kustarz wrote:
> 
> > As i understand it, the open owner has gone from an object
containing a 
> > name and seqid to just containing a name.  Seems unnecessary to 
> > serialize on just a name.
> 
> The serialisation has nothing to do with the name. The serialisation
> allows you to determine unambiguously which stateid is the current one
> for a given <filehandle,open owner> pair for the case where you have
> multiple OPENs on the wire.
> 
> If you can determine this stateid through other means, then you may
not
> need to serialise.

It would likely ease the client implementation if it could count on the 
server returning a different stateid (seqid++) at each state changing
operation.  Is there interest in enforcing this stateid behavior so
the client's can have multiple OPENs in flight?

Spencer

_______________________________________________
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: Mon, 21 Aug 2006 15:57:52 -0400

> when it is too late, i.e. when his open is destroyed by the 

CLOSE takes a stateid argument. It will not close the parallel open
unless the client screwed up royally and sent an incorrect stateid.

Cheers,
  Trond