xfs
[Top] [All Lists]

Re: [PATCH 09/18] nfsd: implement pNFS operations

To: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH 09/18] nfsd: implement pNFS operations
From: Christoph Hellwig <hch@xxxxxx>
Date: Fri, 9 Jan 2015 18:16:41 +0100
Cc: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, thomas.haynes@xxxxxxxxxxxxxxx, trond.myklebust@xxxxxxxxxxxxxxx, Sachin Bhamare <sachin.bhamare@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150109085130.0f862d24@xxxxxxxxxxxxxxxxxxxxxxxxx>
References: <1420561721-9150-1-git-send-email-hch@xxxxxx> <1420561721-9150-10-git-send-email-hch@xxxxxx> <20150108164851.03b64e16@xxxxxxxxxxxxxxxxxxxxxxxxx> <20150109100551.GA23173@xxxxxx> <20150109085130.0f862d24@xxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
On Fri, Jan 09, 2015 at 08:51:30AM -0800, Jeff Layton wrote:
> Ok, it'd be good to document that in some comments then for the sake of
> posterity (maybe it is later in the set -- I haven't gotten to the end
> yet).

What kinds of comments do you expect?  Not implementing unused features
of a protocol should be the default for anything in Linux.

> Now, that said...I think that your ROC semantics are wrong here. You
> also have to take delegations into account. [1]
> 
> Basically the semantics that you want are that nfsd should do all of
> the ROC stuff on last close iff there are no outstanding delegations or
> on delegreturn iff there are no opens.
> 
> What we ended up doing in the unreleased code we have was to create a
> new per-client and per-file object (that we creatively called an
> "odstate"). An open stateid and a delegation stateid would hold a
> reference to this object which is put when those stateids are freed.
> When its refcount goes to zero, then we'd free any outstanding layouts
> on the file for that client and free the object.
> 
> You probably want to do something similar here.
> 
> [1]: Tom and Trond mentioned that there's a RFC5661 errata pending for
>      this, but I don't see it right offhand.

It would be good to look at the errata.  While the idea of keeping
layouts around longer makes sense, I would only expect to do this
if they layout state was created based on a delegation stateid, not
a lock or open stateid.  In that case having the layouts hang off
the "parent" stateid might be another option.

<Prev in Thread] Current Thread [Next in Thread>