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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 21 Aug 2006 16:10:44 -0400

I don't understand your claim.  I think this may be yet 
another instance of the fact that everybody seems to have 
his own different clear idea of how stateids work.

So let us suppose that X and Y are two hard links and
that an openowner opens X for read and then in parallel,
the same openowner closes the stateid he got opening X
and opens Y for write.  How do assume this will play out
for the two diffecrent orders of the open of Y and the
close?

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 3:58 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]
Subject: RE: [nfsv4] parallel opens in NFSv4.1 ?

On Mon, 2006-08-21 at 15:53 -0400, Noveck, Dave wrote:
> > 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.

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 21 Aug 2006 16:24:01 -0400

> for the two diffecrent orders of the open of Y and the

A server is supposed to be able to fence off replayed READ/WRITE
requests even after the CLOSE. A reopen of the file shouldn't normally
open the floodgates to replayed requests.
I would assume that the server will have some form of uniquefier in the
stateid (e.g. a stateid generation counter) to ensure that the two
stateid spaces do not collide.

Cheers,
   Trond