From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Neil Brown <neilb@suse.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
"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:20:10 -0500 [thread overview]
Message-ID: <1265235610.5217.21.camel@localhost> (raw)
In-Reply-To: <20100204082354.0bf3b7e5@notabene.brown>
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.
Cheers
Trond
next prev parent reply other threads:[~2010-02-03 22:20 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 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 [this message]
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
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 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 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=1265235610.5217.21.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