From: Scott Lovenberg <scott.lovenberg@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
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, sven.breuner@itwm.fraunhofer.de
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call
Date: Mon, 16 Apr 2012 15:43:04 -0400 [thread overview]
Message-ID: <4F8C7648.8000701@gmail.com> (raw)
In-Reply-To: <20120416134642.1754cd3e@corrin.poochiereds.net>
On 4/16/2012 1:46 PM, Jeff Layton wrote:
> NFS will generally return a different error if the process catches a
> fatal signal, so a soft mount should not be necessary and is not
> recommended anyway...
>
> In any case, we loop indefinitely now in the NFS code when (for
> instance) there's a loss of communication. Users are not generally
> happy if that causes an error, since their applications start dying.
>
From the peanut gallery, I've always set an infinite loop with an
exponential backoff on the loss of communication. IE, in some code I
wrote for S3backer (a FUSE file system on top of Amazon EC3) a few years
ago (committed by Archie Cobbs).
The trade off is that your applications will try to submit requests if
you don't tell them "leave me alone, I can't service you now". The more
I think about it, the more it seems like failing silently. Isn't the
rule supposed to be "if you must fail, do it loudly and as soon as
possible"? Just my $0.02. Take it as you will.
next prev parent reply other threads:[~2012-04-16 19:42 UTC|newest]
Thread overview: 81+ 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 12:02 ` Jim Rees
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
2012-04-13 17:34 ` Peter Staubach
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-16 14:23 ` Bernd Schubert
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 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 19:33 ` Myklebust, Trond
2012-04-16 19:43 ` Jeff Layton
2012-04-16 20:25 ` Myklebust, Trond
2012-04-16 23:05 ` Jeff Layton
2012-04-17 11:46 ` Steve Dickson
2012-04-17 13:36 ` Jeff Layton
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 16:03 ` Jeff Layton
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:04 ` Myklebust, Trond
2012-04-17 14:20 ` Jeff Layton
2012-04-17 15:45 ` J. Bruce Fields
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:48 ` Peter Staubach
2012-04-18 15:16 ` Jeff Layton
2012-04-16 19:43 ` Scott Lovenberg [this message]
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-20 14:40 ` Jeff Layton
2012-04-20 20:18 ` Steve Dickson
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 13:00 ` J. Bruce Fields
2012-04-23 13:12 ` Jeff Layton
2012-04-23 13:34 ` J. Bruce Fields
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:23 ` Miklos Szeredi
2012-04-23 17:45 ` Peter Staubach
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-23 14:55 ` Steve Dickson
2012-04-23 15:32 ` Jeff Layton
2012-04-23 18:06 ` Steve Dickson
2012-04-23 18:33 ` Jeff Layton
2012-04-23 20:38 ` Peter Staubach
2012-04-24 14:50 ` Jeff Layton
2012-04-24 15:54 ` Miklos Szeredi
2012-04-24 16:34 ` Jeff Layton
2012-04-25 9:41 ` Miklos Szeredi
2012-04-25 12:04 ` Jeff Layton
2012-04-23 17:43 ` Peter Staubach
2012-04-23 19:06 ` Malahal Naineni
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=4F8C7648.8000701@gmail.com \
--to=scott.lovenberg@gmail.com \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=hch@infradead.org \
--cc=jlayton@redhat.com \
--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=sven.breuner@itwm.fraunhofer.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).