From: Michel Lespinasse <walken-Y93EPB1FQwg@public.gmane.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Fwd: NFS 5-minute hangs upon S3 resume using 2.6.27 client
Date: Fri, 24 Oct 2008 14:02:16 -0700 [thread overview]
Message-ID: <20081024210216.GA20386@zoy.org> (raw)
In-Reply-To: <1224851368.22672.20.camel@localhost>
On Fri, Oct 24, 2008 at 08:29:28AM -0400, Trond Myklebust wrote:
> On Thu, 2008-10-23 at 23:57 -0700, Michel Lespinasse wrote:
> > I applied this on top of the previous patch and it worked - but now I'm
> > not sure if you wanted to test this as an independant patch ???
> It was meant to be applied incrementally on top of the other.
OK. Worked fine, then. Thanks again !
> > Can I propose a patch too ? mine looks quite similar to your second patch,
> > but with the reestablish_timeout logic hopefully simplified...
>
> This would cause a different regression. The current code is there in
> order to ensure that we apply that exponential backoff if and only if
> the _server_ closes the TCP connection since that would usually indicate
> that it is trying to deal with a resource congestion issue. We don't
> need to back off if we were the ones closing the socket.
So the idea is to backoff if the connection is closed by a server FIN but
retry right away if it's closed by a RST ?
I did not realize that, but this makes sense too...
> The issue of UDP exponential backoff is moot: the UDP code doesn't use
> xs_connect() at all.
Hrmmm ? I see the following down the file:
static struct rpc_xprt_ops xs_udp_ops = {
...
.connect = xs_connect,
...
}
I'm not sure if/when the callback is actually called in the UDP case,
but it's definitely being set up that way.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
prev parent reply other threads:[~2008-10-24 21:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 4:02 Fwd: NFS 5-minute hangs upon S3 resume using 2.6.27 client Michel Lespinasse
[not found] ` <20081023040231.GA13512-Y93EPB1FQwg@public.gmane.org>
2008-10-23 15:36 ` Trond Myklebust
2008-10-23 19:52 ` Michel Lespinasse
[not found] ` <20081023195231.GA2090-Y93EPB1FQwg@public.gmane.org>
2008-10-23 23:17 ` Trond Myklebust
2008-10-24 6:57 ` Michel Lespinasse
[not found] ` <20081024065759.GA2401-Y93EPB1FQwg@public.gmane.org>
2008-10-24 12:29 ` Trond Myklebust
2008-10-24 21:02 ` Michel Lespinasse [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=20081024210216.GA20386@zoy.org \
--to=walken-y93epb1fqwg@public.gmane.org \
--cc=linux-nfs@vger.kernel.org \
--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.