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? Cheers Trond -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
