public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 6/9] sunrpc: close connection when a request is irretrievably lost.
Date: Wed, 03 Feb 2010 19:24:18 -0500	[thread overview]
Message-ID: <1265243058.2632.23.camel@localhost> (raw)
In-Reply-To: <4B6A0F7A.3090600@oracle.com>

On Wed, 2010-02-03 at 19:06 -0500, Chuck Lever wrote: 
> My only concern would be that we perhaps should not assume that every 
> 2.6 NFS client does this.  There was an awful lot of churn at one point 
> as you were getting all of these ducks in a row.  Before you changed the 
> underlying RPC transports to return only ENOTCONN, for instance, was 
> this behavior the same?  I wouldn't swear to it in the 2.6.7 - .9 
> vintage kernels.

Every change in this area is performance sensitive, and should certainly
be tested carefully; particularly so with older kernels.

However we shouldn't forget that the changes to the client were
motivated by poor performance against a variety of servers, in a variety
of workloads and so it isn't unreasonable to expect that SUSE, Red Hat,
Debian, Oracle, etc do have an interest in fixing their NFS clients.

My question would rather therefore be: do they already have a fix in
their latest kernel revisions, and if not, are they able to give us a
timeframe?

Cheers
  Trond


  reply	other threads:[~2010-02-04  0:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03  6:31 [PATCH 0/9] Cache deferal improvements - try++ NeilBrown
     [not found] ` <20100203060657.12945.27293.stgit-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-02-03  6:31   ` [PATCH 5/9] nfsd/idmap: drop special request deferal in favour of improved default NeilBrown
2010-02-03  6:31   ` [PATCH 1/9] sunrpc: don't keep expired entries in the auth caches NeilBrown
     [not found]     ` <20100203063130.12945.29226.stgit-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-03-15  0:58       ` J. Bruce Fields
2010-02-03  6:31   ` [PATCH 4/9] sunrpc/cache: allow threads to block while waiting for cache update NeilBrown
2010-04-15 15:55     ` J. Bruce Fields
2010-02-03  6:31   ` [PATCH 7/9] nfsd: factor out hash functions for export caches NeilBrown
     [not found]     ` <20100203063131.12945.38791.stgit-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-03-17 19:35       ` J. Bruce Fields
2010-02-03  6:31   ` [PATCH 9/9] sunrpc/cache: change deferred-request hash table to use hlist NeilBrown
2010-02-03  6:31   ` [PATCH 6/9] sunrpc: close connection when a request is irretrievably lost NeilBrown
2010-02-03 15:43     ` Chuck Lever
2010-02-03 21:23       ` Neil Brown
2010-02-03 22:20         ` Trond Myklebust
2010-02-03 22:34           ` J. Bruce Fields
2010-02-03 22:40           ` Chuck Lever
2010-02-03 23:13             ` Trond Myklebust
2010-02-04  0:06               ` Chuck Lever
2010-02-04  0:24                 ` Trond Myklebust [this message]
2010-02-03 22:34         ` Chuck Lever
2010-02-03  6:31   ` [PATCH 8/9] svcauth_gss: replace a trivial 'switch' with an 'if' NeilBrown
2010-02-03  6:31   ` [PATCH 3/9] sunrpc: never return expired entries in sunrpc_cache_lookup NeilBrown
     [not found]     ` <20100203063131.12945.97779.stgit-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-03-17 21:33       ` J. Bruce Fields
2010-03-24  1:22         ` Neil Brown
2010-03-30 15:11           ` J. Bruce Fields
2010-02-03  6:31   ` [PATCH 2/9] sunrpc/cache: factor out cache_is_expired NeilBrown
     [not found]     ` <20100203063131.12945.65321.stgit-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-03-15  0:58       ` J. Bruce Fields
2010-02-03 19:43   ` [PATCH 0/9] Cache deferal improvements - try++ J. Bruce Fields

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=1265243058.2632.23.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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