All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: Marc Eshel <eshel@almaden.ibm.com>,
	andros@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/3] NFSD EOS deferral
Date: Mon, 20 Oct 2008 14:06:37 -0400	[thread overview]
Message-ID: <20081020180637.GB23927@fieldses.org> (raw)
In-Reply-To: <RTPCLUEXC1-PRDarcR4000001cd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>

On Fri, Oct 17, 2008 at 04:51:00PM -0400, Talpey, Thomas wrote:
> At 04:36 PM 10/17/2008, J. Bruce Fields wrote:
> >On Fri, Oct 17, 2008 at 04:26:18PM -0400, Talpey, Thomas wrote:
> >> At 02:59 PM 10/17/2008, Marc Eshel wrote:
> >> >linux-nfs-owner@vger.kernel.org wrote on 10/17/2008 10:44:54 AM:
> >> >
> >> >> "J. Bruce Fields" <bfields@fieldses.org> 
> >> >> Requests longer than a page are still not deferred, so large writes that
> >> >> trigger upcalls still get an ERR_DELAY.  OK, probably no big deal.
> >> >> 
> >> >> I don't think we can apply this until we have some way to track the
> >> >> number and size of deferred requests outstanding and fall back on
> >> >> ERR_DELAY if it's too much.
> >> >
> >> >But I thought that the problem here is that the Linux NFS client doesn't 
> >> >handle this return code properly.
> >> 
> >> Definitely this is an issue. Early clients do one of two things, they either
> >> pass the error back to the application, or they enter a buzz loop resending
> >> the operation with no delay. Later clients back off, but for a constant
> >> five seconds.
> >
> >I haven't tested it, but from fs/nfs/nfs4proc.c:nfs4_delay() it appears
> >to start at a tenth of a second and then do exponential backoff (up to
> >15 seconds).  Looks to me like the code's been that way since at least
> >2.6.19.
> 
> I was referring to NFSv3, actually - also impacted by this codepath.

OK, sorry.

Hm, taking another look: nfs3_rpc_wrapper() uses a constant 5 second
delay, and nfs4_async_handle_error() uses a constant 15 second delay, so
it's only nfs4_handle_exception that does the exponential backoff.
Maybe we could fix that.

--b.

> But I'll take the opportunity to point out that we'll get 5 retries from
> an NFSv4 client before 2 seconds go by, and only one from NFSv3
> in twice that. In either case, it's a heck of a bad trade to return "I'm
> busy" only to have your bell rung repeatedly in response.
> 
> Sorry, I have always hated EJUKEBOX.

  parent reply	other threads:[~2008-10-20 18:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 21:00 [PATCH 0/3] NFSD EOS deferral andros
2008-10-15 21:00 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros
2008-10-15 21:00   ` [PATCH 2/3] NFSD save, restore, and release deferred result pages andros
2008-10-15 21:00     ` [PATCH 3/3] NFSD deferral processing andros
2008-10-17 20:46       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDNY30k000001cc-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 17:58           ` J. Bruce Fields
2008-10-17 17:48   ` [PATCH 1/3] SUNRPC add deferral processing callbacks J. Bruce Fields
2008-10-17 18:42     ` Andy Adamson
2008-10-17 20:35   ` Talpey, Thomas
     [not found]     ` <RTPCLUEXC1-PRDf3sll000001cb-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:42       ` J. Bruce Fields
2008-10-17 17:44 ` [PATCH 0/3] NFSD EOS deferral J. Bruce Fields
2008-10-17 18:44   ` Andy Adamson
2008-10-17 18:59   ` Marc Eshel
     [not found]     ` <OF9E4C4BA6.37418EC7-ON882574E5.0067FB2B-882574E5.0068487F@ us.ibm.com>
2008-10-17 20:26       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDidcDj000001ca-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-17 20:36           ` J. Bruce Fields
2008-10-17 20:51             ` Talpey, Thomas
     [not found]               ` <RTPCLUEXC1-PRDarcR4000001cd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:06                 ` J. Bruce Fields [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-10-22 18:12 andros

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=20081020180637.GB23927@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Thomas.Talpey@netapp.com \
    --cc=andros@netapp.com \
    --cc=eshel@almaden.ibm.com \
    --cc=linux-nfs@vger.kernel.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.