All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: Malahal Naineni <malahal@us.ibm.com>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, pstaubach@exagrid.com,
	miklos@szeredi.hu, viro@ZenIV.linux.org.uk, hch@infradead.org,
	michael.brantley@deshaw.com
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call
Date: Fri, 13 Apr 2012 13:10:35 -0400	[thread overview]
Message-ID: <20120413131035.79ebc2d0@tlielax.poochiereds.net> (raw)
In-Reply-To: <4F884F32.7010402@RedHat.com>

On Fri, 13 Apr 2012 12:07:14 -0400
Steve Dickson <SteveD@redhat.com> wrote:

> 
> 
> On 04/13/2012 11:42 AM, Jeff Layton wrote:
> > On Fri, 13 Apr 2012 10:05:18 -0500
> > Malahal Naineni <malahal@us.ibm.com> wrote:
> > 
> >> Jeff Layton [jlayton@redhat.com] wrote:
> >>> 1) should we retry these calls on all filesystems, or attempt to have
> >>> them "opt-in" in some fashion? This patch adds a flag for that, but
> >>> we could just treat all filesystems the same way.
> >>
> >> I don't know any cases where a retry on ESTALE would hurt. I would say
> >> retry on all file systems the same way.
> >>
> >>> 2) How many times should we retry on an ESTALE error? Once?
> >>> Indefinitely? Some amount in between? Retrying once would probably
> >>> fix the bulk of the real world problems with this, but there will
> >>> still be cases where that's not sufficient.
> >>
> >> As you say 1 retry should work in most cases. Indefinitely doesn't make
> >> sense, I would rather let my application fail! How about 3 retries (3 is
> >> a nice number! :-) )
> >>
> > 
> > (note: please don't trim the CC list!)
> > 
> > Indefinitely does make some sense (as Peter articulated in his original
> > set). It's possible you could race several times in a row, or a server
> > misconfiguration or something has happened and you have a transient
> > error that will eventually recover. His assertion was that any limit on
> > the number of retries is by definition wrong. For NFS, a fatal signal
> > ought to interrupt things as well, so retrying indefinitely has some
> > appeal there.
> > 
> > OTOH, we do have to contend with filesystems that might return ESTALE
> > persistently for other reasons and that might not respond to signals.
> > Miklos pointed out that some FUSE fs' do this in his review of Peter's
> > set.
> > 
> > As a purely defensive coding measure, limiting the number of retries to
> > something finite makes sense. If we're going to do that though, I'd
> > probably recommend that we set the number of retries be something
> > higher just so that this is more resilient in the face of multiple
> > races. Those other fs' might "spin" a bit in that case but it is an
> > error condition and IMO resiliency trumps performance -- at least in
> > this case.
> I'm of the opinion retry more than once has the potential of 
> doing more harm than good... Why introduce looping when there
> is no solid evidence its even needed. 
> 
> I would think 99% of the time the one try would solve the problem. 
> That 1% probably due two apps that have gone wild fight over the same 
> file or the FUSE case. In those cases the error should be returned
> IMHO... 
> 
> steved.
> 

My only real concern with doing that is that again we're going to have
to alter every path-based syscall. If we decide later that retrying
once isn't sufficient, then we'll be stuck doing it again.

That said, it would jive better with the existing ESTALE retry in the
lookup code.

-- 
Jeff Layton <jlayton@redhat.com>

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Steve Dickson <SteveD-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Malahal Naineni <malahal-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	pstaubach-83r9SdEf25FBDgjK7y7TUQ@public.gmane.org,
	miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org,
	viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	michael.brantley-Iq/kdjr4a97QT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call
Date: Fri, 13 Apr 2012 13:10:35 -0400	[thread overview]
Message-ID: <20120413131035.79ebc2d0@tlielax.poochiereds.net> (raw)
In-Reply-To: <4F884F32.7010402-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>

On Fri, 13 Apr 2012 12:07:14 -0400
Steve Dickson <SteveD-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> 
> 
> On 04/13/2012 11:42 AM, Jeff Layton wrote:
> > On Fri, 13 Apr 2012 10:05:18 -0500
> > Malahal Naineni <malahal-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> >> Jeff Layton [jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
> >>> 1) should we retry these calls on all filesystems, or attempt to have
> >>> them "opt-in" in some fashion? This patch adds a flag for that, but
> >>> we could just treat all filesystems the same way.
> >>
> >> I don't know any cases where a retry on ESTALE would hurt. I would say
> >> retry on all file systems the same way.
> >>
> >>> 2) How many times should we retry on an ESTALE error? Once?
> >>> Indefinitely? Some amount in between? Retrying once would probably
> >>> fix the bulk of the real world problems with this, but there will
> >>> still be cases where that's not sufficient.
> >>
> >> As you say 1 retry should work in most cases. Indefinitely doesn't make
> >> sense, I would rather let my application fail! How about 3 retries (3 is
> >> a nice number! :-) )
> >>
> > 
> > (note: please don't trim the CC list!)
> > 
> > Indefinitely does make some sense (as Peter articulated in his original
> > set). It's possible you could race several times in a row, or a server
> > misconfiguration or something has happened and you have a transient
> > error that will eventually recover. His assertion was that any limit on
> > the number of retries is by definition wrong. For NFS, a fatal signal
> > ought to interrupt things as well, so retrying indefinitely has some
> > appeal there.
> > 
> > OTOH, we do have to contend with filesystems that might return ESTALE
> > persistently for other reasons and that might not respond to signals.
> > Miklos pointed out that some FUSE fs' do this in his review of Peter's
> > set.
> > 
> > As a purely defensive coding measure, limiting the number of retries to
> > something finite makes sense. If we're going to do that though, I'd
> > probably recommend that we set the number of retries be something
> > higher just so that this is more resilient in the face of multiple
> > races. Those other fs' might "spin" a bit in that case but it is an
> > error condition and IMO resiliency trumps performance -- at least in
> > this case.
> I'm of the opinion retry more than once has the potential of 
> doing more harm than good... Why introduce looping when there
> is no solid evidence its even needed. 
> 
> I would think 99% of the time the one try would solve the problem. 
> That 1% probably due two apps that have gone wild fight over the same 
> file or the FUSE case. In those cases the error should be returned
> IMHO... 
> 
> steved.
> 

My only real concern with doing that is that again we're going to have
to alter every path-based syscall. If we decide later that retrying
once isn't sufficient, then we'll be stuck doing it again.

That said, it would jive better with the existing ESTALE retry in the
lookup code.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-04-13 17:10 UTC|newest]

Thread overview: 134+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 11:25 [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call Jeff Layton
2012-04-13 11:25 ` Jeff Layton
2012-04-13 12:02 ` Jim Rees
2012-04-13 12:02   ` Jim Rees
2012-04-13 12:09   ` Jeff Layton
2012-04-13 12:09     ` Jeff Layton
2012-04-13 15:05 ` Malahal Naineni
2012-04-13 15:42   ` Jeff Layton
2012-04-13 16:07     ` Steve Dickson
2012-04-13 17:10       ` Jeff Layton [this message]
2012-04-13 17:10         ` Jeff Layton
2012-04-13 17:34       ` Peter Staubach
2012-04-13 17:34         ` Peter Staubach
2012-04-13 23:00         ` Jeff Layton
2012-04-13 23:00           ` Jeff Layton
2012-04-14  0:57         ` Trond Myklebust
2012-04-15 19:03     ` Bernd Schubert
2012-04-15 19:27       ` J. Bruce Fields
2012-04-15 19:27         ` J. Bruce Fields
2012-04-16 14:23         ` Bernd Schubert
2012-04-15 19:57       ` Chuck Lever
2012-04-15 19:57         ` Chuck Lever
2012-04-16 11:23         ` Jeff Layton
2012-04-17 11:53         ` Steve Dickson
2012-04-16 11:36       ` Jeff Layton
2012-04-16 11:36         ` Jeff Layton
2012-04-16 12:54         ` Peter Staubach
2012-04-16 12:54           ` Peter Staubach
2012-04-16 16:04           ` Jeff Layton
2012-04-16 14:44         ` Bernd Schubert
2012-04-16 17:46           ` Jeff Layton
2012-04-16 17:46             ` Jeff Layton
2012-04-16 19:33             ` Myklebust, Trond
2012-04-16 19:33               ` Myklebust, Trond
2012-04-16 19:33               ` Myklebust, Trond
2012-04-16 19:43               ` Jeff Layton
2012-04-16 20:25                 ` Myklebust, Trond
2012-04-16 20:25                   ` Myklebust, Trond
2012-04-16 20:25                   ` Myklebust, Trond
2012-04-16 23:05                   ` Jeff Layton
2012-04-17 11:46                     ` Steve Dickson
2012-04-17 11:46                       ` Steve Dickson
2012-04-17 13:36                       ` Jeff Layton
2012-04-17 13:36                         ` Jeff Layton
2012-04-17 14:14                         ` Steve Dickson
2012-04-17 14:14                           ` Steve Dickson
2012-04-17 14:27                           ` Miklos Szeredi
2012-04-17 15:02                             ` Jeff Layton
2012-04-17 15:50                               ` Miklos Szeredi
2012-04-17 15:50                                 ` Miklos Szeredi
2012-04-17 16:03                                 ` Jeff Layton
2012-04-17 16:03                                   ` Jeff Layton
2012-04-17 15:59                               ` Steve Dickson
2012-04-17 15:59                                 ` Steve Dickson
2012-04-17 13:12                     ` Miklos Szeredi
2012-04-17 13:32                       ` Jeff Layton
2012-04-17 14:03                         ` Miklos Szeredi
2012-04-17 14:22                           ` Jeff Layton
2012-04-17 14:22                             ` Jeff Layton
2012-04-17 14:04                         ` Myklebust, Trond
2012-04-17 14:04                           ` Myklebust, Trond
2012-04-17 14:04                           ` Myklebust, Trond
2012-04-17 14:20                           ` Jeff Layton
2012-04-17 15:45                             ` J. Bruce Fields
2012-04-17 15:45                               ` J. Bruce Fields
2012-04-17 16:02                               ` Miklos Szeredi
2012-04-17 16:02                                 ` Miklos Szeredi
2012-04-17 13:39                     ` Peter Staubach
2012-04-17 14:08                       ` Myklebust, Trond
2012-04-17 14:08                         ` Myklebust, Trond
2012-04-17 14:08                         ` Myklebust, Trond
2012-04-17 14:48                         ` Peter Staubach
2012-04-17 14:48                           ` Peter Staubach
2012-04-17 14:48                           ` Peter Staubach
2012-04-18 15:16                           ` Jeff Layton
2012-04-18 15:16                             ` Jeff Layton
2012-04-16 19:43             ` Scott Lovenberg
2012-04-16 19:43               ` Scott Lovenberg
2012-04-16 16:55 ` [PATCH RFC v2] " Jeff Layton
2012-04-18 11:52 ` [PATCH RFC v3] vfs: make fstatat retry once " Jeff Layton
2012-04-18 11:52   ` Jeff Layton
2012-04-20 14:40   ` Jeff Layton
2012-04-20 20:18     ` Steve Dickson
2012-04-20 20:18       ` Steve Dickson
2012-04-20 20:37       ` Malahal Naineni
2012-04-20 20:37         ` Malahal Naineni
2012-04-20 21:13         ` Jeff Layton
2012-04-22  5:40           ` Miklos Szeredi
2012-04-23 12:00             ` Jeff Layton
2012-04-23 12:00               ` Jeff Layton
2012-04-23 13:00               ` J. Bruce Fields
2012-04-23 13:00                 ` J. Bruce Fields
2012-04-23 13:12                 ` Jeff Layton
2012-04-23 13:12                   ` Jeff Layton
2012-04-23 13:34                   ` J. Bruce Fields
2012-04-23 13:34                     ` J. Bruce Fields
2012-04-23 13:50                     ` Jeff Layton
2012-04-23 13:50                       ` Jeff Layton
2012-04-23 13:54                       ` J. Bruce Fields
2012-04-23 14:51                         ` Miklos Szeredi
2012-04-23 15:02                           ` Chuck Lever
2012-04-23 15:02                             ` Chuck Lever
2012-04-23 15:23                             ` Miklos Szeredi
2012-04-23 17:45                               ` Peter Staubach
2012-04-23 15:16                           ` Jeff Layton
2012-04-23 15:16                             ` Jeff Layton
2012-04-23 15:28                             ` Miklos Szeredi
2012-04-23 18:59                               ` Jeff Layton
2012-04-20 21:13       ` Jeff Layton
2012-04-20 21:13         ` Jeff Layton
2012-04-23 14:55         ` Steve Dickson
2012-04-23 14:55           ` Steve Dickson
2012-04-23 15:32           ` Jeff Layton
2012-04-23 15:32             ` Jeff Layton
2012-04-23 18:06             ` Steve Dickson
2012-04-23 18:06               ` Steve Dickson
2012-04-23 18:33               ` Jeff Layton
2012-04-23 20:38               ` Peter Staubach
2012-04-23 20:38                 ` Peter Staubach
2012-04-24 14:50                 ` Jeff Layton
2012-04-24 15:54                   ` Miklos Szeredi
2012-04-24 15:54                     ` Miklos Szeredi
2012-04-24 16:34                     ` Jeff Layton
2012-04-25  9:41                       ` Miklos Szeredi
2012-04-25  9:41                         ` Miklos Szeredi
2012-04-25 12:04                         ` Jeff Layton
2012-04-25 12:04                           ` Jeff Layton
2012-04-23 17:43           ` Peter Staubach
2012-04-23 17:43             ` Peter Staubach
2012-04-23 19:06           ` Malahal Naineni
2012-04-23 19:06             ` Malahal Naineni
2012-04-22  4:16     ` Ric Wheeler
2012-04-22  4:16       ` Ric Wheeler
2012-04-23 11:20       ` Jeff Layton

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=20120413131035.79ebc2d0@tlielax.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=SteveD@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=malahal@us.ibm.com \
    --cc=michael.brantley@deshaw.com \
    --cc=miklos@szeredi.hu \
    --cc=pstaubach@exagrid.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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.