Re: nfs4_file usage

[Benny Halevy <bhalevy@primarydata.com>]

On 2013-10-16 15:33, Christoph Hellwig wrote:
> On Wed, Oct 16, 2013 at 03:18:21PM +0300, Benny Halevy wrote:
>> The nfs4.1 layout stateid is like any other stateid (open/lock/deleg)
>> but it's life time is a bit different as it is not descending from the
>> open stateid (though the protocol requires the client to use it
>> to acquire the first layout for the file) and it is released via
>> either LAYOUTRETURN or CLOSE (in the "return_on_close" case).
>> The rules here are different enough from open/lock/deleg stateids that
>> pnfsd needs special code to handle the management of the actual layout state
>> under the layout stateid and manipulate it accordingly.
> 
> I'm not primarily ocnfused about the protocol even if that isn't all
> that clear either.  I'm more worried about the code in and around
> nfs4_find_create_layout_stateid.  I have looked a bit deeper into it
> and I think the main problem is that struct nfs4_stid isn't refcounted
> by itself, which really confused me expecting nfsd4_lookup_stateid
> to return a reference to it.
> 

True.  That is likely to change with the state lock elimination project
where a stateid would get refcounted once found and its pointer is returned to
the caller.