From: Benny Halevy <bhalevy@panasas.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Peter Staubach <staubach@redhat.com>,
chucklever@gmail.com, Andrew Bell <andrew.bell.ia@gmail.com>,
linux-nfs@vger.kernel.org
Subject: Re: Performance Diagnosis
Date: Wed, 16 Jul 2008 10:35:15 +0300 [thread overview]
Message-ID: <487DA4B3.1070805@panasas.com> (raw)
In-Reply-To: <1216150552.7981.48.camel@localhost>
On Jul. 15, 2008, 22:35 +0300, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Tue, 2008-07-15 at 15:21 -0400, Peter Staubach wrote:
>> The connection manager would seem to be a RPC level thing, although
>> I haven't thought through the ramifications of the NFSv4.1 stuff
>> and how it might impact a connection manager sufficiently.
>
> We already have the scheme that shuts down connections on inactive RPC
> clients after a suitable timeout period, so the only gains I can see
> would have to involve shutting down connections on active clients.
>
> At that point, the danger isn't with NFSv4.1, it is rather with
> NFSv2/3/4.0... Specifically, their lack of good replay cache semantics
> mean that you have to be very careful about schemes that involve
> shutting down connections on active RPC clients.
One more thing to consider about nfsv4.1 is the back channel which
uses one of the forward going connections. You may need to keep it
alive while you hold state on the client (data/dir delegations, layouts,
etc.)
Benny
>
> Cheers
> Trond
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2008-07-16 7:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 15:34 Performance Diagnosis Andrew Bell
[not found] ` <e80abd30807150834m47a1b86cle39885150f1d5bfd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-15 15:49 ` Chuck Lever
2008-07-15 15:58 ` Peter Staubach
2008-07-15 16:23 ` Chuck Lever
[not found] ` <76bd70e30807150923r31027edxb0394a220bbe879b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-15 16:34 ` Andrew Bell
[not found] ` <e80abd30807150934tc14e793ydd7aae44b4c3111b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-15 17:20 ` Chuck Lever
2008-07-15 17:44 ` Peter Staubach
2008-07-15 18:17 ` Chuck Lever
[not found] ` <76bd70e30807151117g520f22cj1dfe26b971987d38-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-15 18:51 ` Trond Myklebust
2008-07-15 19:21 ` Peter Staubach
2008-07-15 19:35 ` Trond Myklebust
2008-07-15 19:55 ` Peter Staubach
2008-07-15 20:27 ` Trond Myklebust
2008-07-15 20:48 ` Peter Staubach
2008-07-15 21:15 ` Talpey, Thomas
2008-07-16 7:35 ` Benny Halevy [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=487DA4B3.1070805@panasas.com \
--to=bhalevy@panasas.com \
--cc=andrew.bell.ia@gmail.com \
--cc=chucklever@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=staubach@redhat.com \
--cc=trond.myklebust@fys.uio.no \
/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