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: <OFC2E514D3.435CB176-ON87256D9F.00553534@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Fri, 12 Sep 2003 10:48:24 -0500

See below.

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

Trond Myklebust <trond.myklebust@fys.uio.no>
Sent by: nfsv4-admin@ietf.org
09/12/2003 09:55 AM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     Trond Myklebust <trond.myklebust@fys.uio.no>, nfsv4@ietf.org, 
nfsv4-admin@ietf.org, spencer.shepler@sun.com
        Subject:        Re: [nfsv4] Out of sync stateid scenario that looks difficult to resolve

>>>>> " " == Carl Burnett <cburnett@us.ibm.com> writes:

     > I think this comes from the property, that within the open
     > stateid, there is a seqid that the server should increment each
     > time it processes an operation that uses the stateid. Thus the
     > stateid continuely moves forward in time. As Spencer hinted,
     > this is an addtion to any info within the opaque portion of the
     > id that the server is managing, which could change with each
     > use of the stateid as well.

No... The open_owner has a seqid, but the stateid is supposed to
obviate the need for a specific seqid once state has been established.
IOW the sequence ids are only required for state changing operations.

[CARL: From the spec -
"                  struct stateid4 {
                    uint32_t        seqid;
                    opaque          other[12];
                  };

   This structure is used for the various state sharing mechanisms
   between the client and server.  For the client, this data structure
   is read-only.  The starting value of the seqid field is undefined.
   The server is required to increment the seqid field monotonically at
   each transition of the stateid.  This is important since the client
   will inspect the seqid in OPEN stateids to determine the order of
   OPEN processing done by the server.
"
I take this to mean OPEN represents a state changing operation.
Thus every open moves the seqid forward. And every object is associated
with some instance of the produced stateid. For that object, the stateid
continues to progress as operations on that stated id occur.
I think a ramification of this is that, in reality, the seqid field
of an open stateid is really a counter maintained in the server's
record of an open_owner. Anytime an open stateid is produced or used,
the associated open_owner must be appropriately consulted and managed.
]

What Spencer rather appears to be stating is rather that stateids may
be invalidated by all state changing operations. As OPEN is such a
state changing operation then he argues it may invalidate a stateid.

[CARL: I could have easily misinterpreted Spencer, but I thought he was
 basically pointing out that the open stateid does in fact change
 with operations, and that for a given object (file), the updated
 stateid becomes the only valid stateid to use with future operations
 on that object. I expect Spencer will post to clarify.
]

This gets ugly because the client does not a priori know which stateid
is going to change before it issues the OPEN. Unlike all other state
changing operations, OPEN takes an open_owner and _path_ argument. The
state that it may modify, however, is tied to an open_owner and
_filehandle_ tuple...

Cheers,
  Trond

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

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