RE: [nfsv4] Out of sync stateid scenario that looks difficult to resolve

cburnett@us.ibm.com

Subject: RE: [nfsv4] Out of sync stateid scenario that looks difficult to resolve
Message-ID: <OF2CD4C251.966EA59E-ON87256DA3.0074871A@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Tue, 16 Sep 2003 16:33:17 -0500

As Paul has stated below, our current approach is the more restrictive one 
that seems to be consistent with what Dave and Spencer have stated for 
Netapp and Sun. We are open to relaxing this, as has been suggested, where 
the server further looks at what access modes are allowed for the object's 
accumulated open rights held by the open owner associated with the 
stateid. It would be nice to get a consensus among the implementers. 
Unfortunately, a client has to code to and handle the most restrictive 
case unless its taken as standard convention to support the more relaxed 
server model. Ideally, while I know its not possible, the spec would be 
updated to be very specific on these aspects of the protocol and not allow 
so much latitude. Given the RFC can't be modified, its in dire need of a 
comprehensive white paper on NFS V4 state management.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Paul Mazzurana/Austin/IBM@IBMUS
Sent by: nfsv4-admin@ietf.org
09/16/2003 03:49 PM

        To:     nfsv4@ietf.org
        cc: 
        Subject:        RE: [nfsv4] Out of sync stateid scenario that looks difficult to resolve

Just wanted to add a data point on how our server will be handling the 
"old" stateid issue.  Our stateids will also be changing by incrementing 
the internal sequence id of the stateid. We will also reject "old" 
stateids on all operations that take a stateid. 

Dave Noveck said: 
So I suppose that you are assuming that the server will shomehow keep 
the information for the previous stateid as well as the new one so that
it can act on the old one before the CONFIRM, act on the new one after
the CONFIRM, and also restore the old one if the confirm does not happen.
Since my server doesn't currently do this, I'm definitely against it :-)
[...deleted...]

Let's take a case.  I have a file open for read and it was state id X 
with seqid 1.  Now, asynchronously some read's are issued with that 
stateid X:1.  Now an open for write is done upgrading the open for that
file (and it may be through a different name) and so you get back, by
hypothesis, stateid X:2.

So if we get a read issued before the open, should we reject it?  After
the upgrade, we will still be able to read, as we can see by looking for
the current privileges recorded in the object for stateid X (in this model
we won't look at the seqid, since the state object has been updated to
include read and write privileges).  Now if somehow the client issued a
write, before the upgrade, then we could see that fact with the seqid,
but is that really an advantage?   [...deleted..]

> and when debugging client and server interaction it is easier to track 
> the transitions that occur with stateids.

This is true but is it worth it?  Our server does currently do this, but
if does add complexity and so if it problematic for clients, and there 
isn't
a big benefit, I'd be inclined to get rid of it.   

And Spencer said: 

The stateid changes in the form of incrementing its internal sequence
id.  Our server implementation currently will reject "old" stateids
for all operations that take a stateid. 

-- 
Paul D. Mazzurana 
AIX - NFS group 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4