[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8C7648.8000701@gmail.com>
Date: Mon, 16 Apr 2012 15:43:04 -0400
From: Scott Lovenberg <scott.lovenberg@...il.com>
To: Jeff Layton <jlayton@...hat.com>
CC: Bernd Schubert <bernd.schubert@...m.fraunhofer.de>,
Malahal Naineni <malahal@...ibm.com>,
linux-nfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, pstaubach@...grid.com,
miklos@...redi.hu, viro@...IV.linux.org.uk, hch@...radead.org,
michael.brantley@...haw.com, sven.breuner@...m.fraunhofer.de
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr
call
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists