Re: Question about open(CLAIM_FH)

[Trond Myklebust <trondmy@hammerspace.com>]

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@hammerspace.com