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
