From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
"bfields@fieldses.org" <bfields@fieldses.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"devel@openvz.org" <devel@openvz.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jlayton@redhat.com" <jlayton@redhat.com>
Subject: Re: [PATCH 0/3] lockd: use per-net refrence-counted NSM clients
Date: Mon, 17 Sep 2012 19:23:49 +0400 [thread overview]
Message-ID: <50574085.90104@parallels.com> (raw)
In-Reply-To: <D4B752F3-1883-490E-AA5D-B9666472FFF3@oracle.com>
17.09.2012 19:10, Chuck Lever пишет:
>
> On Sep 17, 2012, at 6:49 AM, Stanislav Kinsbursky wrote:
>
>> 14.09.2012 23:10, Chuck Lever пишет:
>>>
>>> On Sep 14, 2012, at 1:38 PM, Myklebust, Trond wrote:
>>>
>>>> On Fri, 2012-09-14 at 13:01 -0400, Chuck Lever wrote:
>>>>> What happens if statd is restarted?
>>>>
>>>> Nothing unusual. Why?
>>>
>>> The NSM upcall transport is a potential application for TCP + softconn, now that a persistent rpc_clnt is used. It just depends on what failure mode we'd like to optimize for.
>>>
>>
>> I don't understand, where the problem is.
>> Could you be more specific, please?
>
> I'm suggesting an enhancement.
>
> The change is to use TCP for the NSM upcall transport, and set RPC_TASK_SOFTCONN on the individual RPCs. The advantage of this is that the kernel could discover when statd is not running and fail the upcall immediately, rather than waiting possibly many seconds for each upcall RPC to time out.
>
> The client already has a check in the mount.nfs command to see that statd is running, likely to avoid this lengthly timeout. Since the client already has long-standing logic to avoid it, I think the benefit would be mostly on the server side.
>
> But this change can be done at some later point.
>
Ok, thanks.
Sounds reasonable to me.
I'll do so.
--
Best regards,
Stanislav Kinsbursky
prev parent reply other threads:[~2012-09-17 15:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 14:25 [PATCH 0/3] lockd: use per-net refrence-counted NSM clients Stanislav Kinsbursky
2012-09-14 14:25 ` [PATCH 1/3] lockd: use rpc client's cl_nodename for id encoding Stanislav Kinsbursky
2012-09-14 19:08 ` Chuck Lever
2012-09-17 10:48 ` Stanislav Kinsbursky
2012-09-14 14:26 ` [PATCH 2/3] lockd: per-net NSM client creation and destruction helpers introduced Stanislav Kinsbursky
2012-09-14 14:26 ` [PATCH 3/3] lockd: create and use per-net NSM RPC clients on MON/UNMON requests Stanislav Kinsbursky
2012-09-14 17:01 ` [PATCH 0/3] lockd: use per-net refrence-counted NSM clients Chuck Lever
2012-09-14 17:38 ` Myklebust, Trond
2012-09-14 19:10 ` Chuck Lever
2012-09-17 10:49 ` Stanislav Kinsbursky
2012-09-17 15:10 ` Chuck Lever
2012-09-17 15:23 ` Stanislav Kinsbursky [this message]
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=50574085.90104@parallels.com \
--to=skinsbursky@parallels.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=devel@openvz.org \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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).