All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
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 17:40:34 -0500	[thread overview]
Message-ID: <4B69FB62.2090908@oracle.com> (raw)
In-Reply-To: <1265235610.5217.21.camel@localhost>

On 02/03/2010 05:20 PM, Trond Myklebust wrote:
> On Thu, 2010-02-04 at 08:23 +1100, Neil Brown wrote:
>> On Wed, 03 Feb 2010 10:43:04 -0500
>> Chuck Lever<chuck.lever@oracle.com>  wrote:
>>>
>>> I don't think dropping the connection will cause the client to
>>> retransmit sooner.  Clients I have encountered will reconnect and
>>> retransmit only after their retransmit timeout fires, never sooner.
>>>
>>
>> I thought I had noticed the Linux client resending immediately, but it would
>> have been a while ago, and I could easily be remembering wrongly.
>
> It depends on who closes the connection.
>
> The client assumes that if the _server_ closes the connection, then it
> may be having resource congestion issues. In order to give the server
> time to recover, the client will delay reconnecting for 3 seconds (with
> an exponential back off).
 >
> If, on the other hand, the client was the one that initiated the
> connection closure, then it will try to reconnect immediately.

That's only if there are RPC requests immediately ready to send, though, 
right?  A request that is waiting for a reply when the connection is 
dropped wouldn't be resent until its retransmit timer expired, I thought.

And, this behavior is true only for late-model clients... some of the 
eariler 2.6 clients have some trouble with this scenario, I seem to recall.

-- 
chuck[dot]lever[at]oracle[dot]com

  parent reply	other threads:[~2010-02-03 22:42 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 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 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  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 [this message]
2010-02-03 23:13             ` Trond Myklebust
2010-02-04  0:06               ` Chuck Lever
2010-02-04  0:24                 ` Trond Myklebust
2010-02-03 22:34         ` Chuck Lever
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 9/9] sunrpc/cache: change deferred-request hash table to use hlist NeilBrown
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 8/9] svcauth_gss: replace a trivial 'switch' with an 'if' NeilBrown
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 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=4B69FB62.2090908@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.