Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattrcall

From: Steve Dickson
Date: Tue Apr 17 2012 - 12:00:41 EST

On 04/17/2012 11:02 AM, Jeff Layton wrote:
> On Tue, 17 Apr 2012 16:27:16 +0200
> Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> Steve Dickson <SteveD@xxxxxxxxxx> writes:
>>> True, but even so... Giving file systems an opt-out option with the
>>> default being out, maybe still have some merit... Making file systems
>>> enable this new type of functionality would cut down on any of the
>>> "surprise" that might occur with this redo ;-)
>> I've been arguing for something slightly different for quite some time:
>> I never liked errno values which have side effects in the kernel yet
>> might be visible to userspace.
>> So why not introduce ERETRYSTALE, a *kernel internal* errno value that
>> userspace will never see and filesystems never accidentally set. The
>> VFS can turn this into ESTALE if it doesn't retry for some reason
>> (e.g. already retried).
> That's possible but it's certainly a lot more invasive. It's also far
> more difficult for filesystems to opt-in to this sort of behavior.
> All of the places that call vfs_getattr, for instance will need to be
> fixed up to deal with that sort of error. That will also make it messy
> to do this in any sort of piecemeal fashion. We can't (for instance)
> convert NFSERR_STALE to -ESTALERETRY universally. We'll need to take
> great care only to return that to codepaths that are equipped to deal
> with it.
> Personally, I'd prefer not to foist so much code churn on any filesystem
> that might want to do this sort of retry, but I'll live with it if
> that's the consensus opinion...
I agree with Jeff.... Introducing a new errno is a bit of overkill.. IMHO...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at