Re: [nfsv4] rfc5661 errata 3901, was: Re: [PATCH 09/18] nfsd: implement pNFS operations

[Trond Myklebust <trond.myklebust@primarydata.com>]

On Thu, Jan 15, 2015 at 11:26 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Jan 14, 2015 at 11:16:27AM -0800, Tom Haynes wrote:
>> Christoph,
>>
>> I don't understand this concern. Section 8.2.1:
>>
>> open stateids: OPEN state for a given client ID/open-owner/filehandle triple
>>
>> delegation stateids: A stateid represents a single delegation held by a client for a
>>       particular filehandle.
>>
>> By definition, open/delegation stateids are tracked per
>> file/client combination.
>
> My concern is that the language in errata 3901 says the server should
> invalidate all layouts after all open stateids are closed, and all
> delegation stateids are returned for a given file, which means the
> server needs to add another object just to track the layouts.  If
> on the other hand we say the lifetime of the layouts is tied to
> the open stateid or the delegation stateid used to create the
> layout stateid we can track the outstanding layouts in those
> open/delegation stateid (and the lock stateid as well).
>

The problem, in my mind, is that defeats the main purpose of
return-on-close, which is to reduce the on-the-wire chattiness of the
protocol. How one implements that internally on the server is not
really a concern that should be reflected in the protocol.

Cheers
  Trond