On Thu, 2019-04-18 at 14:38 +0000, Trond Myklebust wrote: > Hi Scott, > > On Thu, 2019-04-18 at 09:37 -0400, Scott Mayhew wrote: > > When the client does an open(CLAIM_FH) and the server already has > > open > > state for that open owner and file, what's supposed to happen? > > Currently the server returns the existing stateid with the seqid > > bumped, > > but it looks like the client is expecting a new stateid (I'm seeing > > the > > state manager spending a lot of time waiting in > > nfs_set_open_stateid_locked() due to NFS_STATE_CHANGE_WAIT being > > set > > in > > the state flags by nfs_need_update_open_stateid()). > > > > Looking at rfc5661 section 18.16.3, I see: > > > > | CLAIM_NULL, CLAIM_FH | For the client, this is a new OPEN > > request | > > | | and there is no previous state > > associated | > > | | with the file for the > > client. With | > > | | CLAIM_NULL, the file is identified by > > the | > > | | current filehandle and the > > specified | > > | | component name. With CLAIM_FH (new > > to | > > | | NFSv4.1), the file is identified by > > just | > > | | the current filehandle. > > > > So it seems like maybe the server should be tossing the old state > > and > > returning a new stateid? > > > > No. As far as the protocol is concerned, the only difference between > CLAIM_NULL and CLAIM_FH is through how the client identifies the file > (in the first case, through an implicit lookup, and in the second > case > through a file handle). The client should be free to intermix the two > types of OPEN, and it should expect the resulting stateids to depend > only on whether or not the open_owner matches. If the open_owner > matches an existing stateid, then that stateid is bumped and > returned. > > I'm not aware of any expectation in the client that this should not > be > the case, so if you are seeing different behaviour, then something > else > must be at work here. Is the client perhaps mounting the same > filesystem in two different places in such a way that the super block > is not being shared? Oh, one thing to note that is both a protocol and a client expectation: if the server returns multiple different filehandles for the same file (i.e. same fsid:fileid combination), then the stateid is attached to the _filehandle_ and not the fsid;fileid combination. So if the server is coded to return a different filehandle in the CLAIM_NULL case than the one used for CLAIM_FH, then that would explain the expectation above. This should never be the case for knfsd. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
