All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Michel Lespinasse <walken-Y93EPB1FQwg@public.gmane.org>
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 08:29:28 -0400	[thread overview]
Message-ID: <1224851368.22672.20.camel@localhost> (raw)
In-Reply-To: <20081024065759.GA2401-Y93EPB1FQwg@public.gmane.org>

On Thu, 2008-10-23 at 23:57 -0700, Michel Lespinasse wrote:
> On Thu, Oct 23, 2008 at 07:17:59PM -0400, Trond Myklebust wrote:
> > > (I'm still concerned about the 3 second delay here...)
> > Does this patch fix that delay?
> > 
> > SUNRPC: Fix the setting of xprt->reestablish_timeout when reconnecting
> 
> 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.

> I'm wondering how the code in xs_tcp_state_change() that sets
> reestablish_timeout back to XS_TCP_INIT_REEST_TO managed to not cause trouble.
> 
> 
> 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.

The issue of UDP exponential backoff is moot: the UDP code doesn't use
xs_connect() at all.

Cheers
  Trond


  parent reply	other threads:[~2008-10-24 12:29 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 [this message]
2008-10-24 21:02                 ` Michel Lespinasse

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=1224851368.22672.20.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-nfs@vger.kernel.org \
    --cc=walken-Y93EPB1FQwg@public.gmane.org \
    /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.