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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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...

steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux