From: Benny Halevy <bhalevy@tonian.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Peng Tao <bergwolf@gmail.com>,
linux-nfs@vger.kernel.org, Peng Tao <peng_tao@emc.com>,
nfsv4 list <nfsv4@ietf.org>
Subject: Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
Date: Mon, 31 Oct 2011 19:08:43 +0200 [thread overview]
Message-ID: <4EAED61B.7030405@tonian.com> (raw)
In-Reply-To: <1320079501.4714.9.camel@lade.trondhjem.org>
On 2011-10-31 18:45, Trond Myklebust wrote:
> On Tue, 2011-11-01 at 00:38 +0800, Peng Tao wrote:
>> On Mon, Oct 31, 2011 at 11:49 PM, Trond Myklebust
>> <Trond.Myklebust@netapp.com> wrote:
>>> On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
>>>> For blocklayout, we need to issue layoutreturn to return layouts when
>>>> handling CB_RECALL_ANY.
>>>
>>> Why?
>> Because replying NFS4_OK to CB_RECALL_ANY indicates that client knows
>> that server wants client to return layout. And server will be waiting
>> for layoutreturn in such case.
>
> No it doesn't. NFS4_OK means that the client acknowledges that it has
> been given a new limit on the number of recallable objects it can keep.
> There is no requirement in the text that it should send layoutreturn or
> that the server should expect that.
The motivation for CB_RECALL_ANY is to reduce the state on the *server* side.
Quoting from RFC5661:
The server may decide that it cannot hold all of the state for
recallable objects, such as delegations and layouts, without running
out of resources. In such a case, while not optimal, the server is
free to recall individual objects to reduce the load.
...
In order to implement an effective reclaim scheme for such objects,
the server's knowledge of available resources must be used to
determine when objects must be recalled with the clients selecting
the actual objects to be returned.
^^^^^^^^^^^^^^
...
When a given resource pool is over-utilized, the server can send a
CB_RECALL_ANY to clients holding recallable objects of the types
involved, allowing it to keep a certain number of such objects and
return any excess.
^^^^^^^^^^^^^^^^^
...
RCA4_TYPE_MASK_FILE_LAYOUT
The client is to return layouts of type LAYOUT4_NFSV4_1_FILES.
^^^^^^^^^^^^^^^^^
Isn't that explicit enough?
>
> In any case, there is no reason to make a difference between block,
> object and file layouts when it comes to CB_RECALL_ANY. The code to
> handle it should be the same for all.
>
Agreed.
Benny
next prev parent reply other threads:[~2011-10-31 17:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 15:15 [PATCH 1/2 RESEND] NFS4: fix cb_recallany decode error Peng Tao
2011-10-31 15:15 ` [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY Peng Tao
2011-10-31 15:49 ` Trond Myklebust
2011-10-31 16:38 ` Peng Tao
2011-10-31 16:45 ` Trond Myklebust
2011-10-31 17:02 ` Peng Tao
2011-10-31 17:08 ` Benny Halevy [this message]
2011-10-31 17:42 ` Trond Myklebust
2011-10-31 17:57 ` Benny Halevy
2011-10-31 18:20 ` Trond Myklebust
2011-10-31 18:23 ` [nfsv4] " Matt W. Benjamin
2011-10-31 18:31 ` Trond Myklebust
2011-10-31 18:31 ` Jim Rees
2011-10-31 18:39 ` Trond Myklebust
2011-11-01 5:29 ` tao.peng
2011-11-04 1:33 ` tao.peng
2011-10-31 21:42 ` [nfsv4] " Welch, Brent
2011-11-01 14:59 ` david.noveck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EAED61B.7030405@tonian.com \
--to=bhalevy@tonian.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bergwolf@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@ietf.org \
--cc=peng_tao@emc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).