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

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

> A reopen of the file shouldn't normally
> open the floodgates to replayed requests.

Don't understand what you are saying here.

> 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.

The issue is that if Y is really the same file as X, 
then an open of Y is an open of X and a close of X 
is a clsoe of Y.  If the open of Y is simply an upgrade
then I wouldn't think there would be a new generation 
of stateid.  Instead, you would have the same stateid
allocation with that stateid upgraded to reflect the
open-for-write.

If you don't think that the "wrong" open file will be
closed, I'd like to understand specifically what you
think will happen when the open of Y and the close happen
in various orders.

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

On Mon, 2006-08-21 at 16:10 -0400, Noveck, Dave wrote:
> 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?

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 21 Aug 2006 17:30:11 -0400

> Don't understand what you are saying here.

I'm saying that the servers should be able to fence away replayed READ
or WRITE requests if they reuse a stateid after a CLOSE. This implies
that they need some method to ensure that old stateids are not reused.

> think will happen when the open of Y and the close happen

If the server receives the OPEN first, then the CLOSE, it should reply
OLD_STATEID to the CLOSE assuming that it granted the OPEN. The client
should then inspect the state resulting from the union of the pre-CLOSE
state and the new OPEN, in order to determine if it needs to send an
OPEN_DOWNGRADE.

If the server receives the CLOSE first, then the OPEN, then it will
presumably return OK to both, and the client can safely use the new
stateid returned by the OPEN.

If the OPEN was not granted, then presumably the CLOSE will always
succeed, and the old stateid will be invalidated.

Cheers,
  Trond