On Mon, 23 Apr 2012 14:06:46 -0400
Steve Dickson <SteveD@xxxxxxxxxx> wrote:
> >
> > It'd be preferable to me if we didn't require a new error code, but if
> > different filesystems require different semantics from the VFS on an
> > ESTALE return, then that is one way to achieve it.
> >
> Well I thought the use of the fs_flags to register for this type
> of semantics was a good one...
>
The problem with that is that you don't have a way to know whether the
fs wants you to retry or not on a lookup. When you get back an ESTALE
on a lookup, then that's all you have. You don't know what fs was
involved. The ERETRYLOOKUP return solves that case nicely.
The problem with the ERETRYLOOKUP idea in other codepaths is that we'll
have a bunch of this kind of crap all over the place in the vfs code:
return rc == -ERETRYLOOKUP ? -ESTALE : rc;
...in order to deal with those codepaths that might call down into the
fs, get that error back and then not actually be able to retry. For
instance, vfs_getattr is called from both vfs_fstat and vfs_fstatat.
The latter can and should retry on an ESTALE, but the former cannot.
That's a relatively simple case though. The real PITA will be stuff
like the inode_permission codepaths which branch out very widely. It'll
be hard to ensure that ERETRYLOOKUP doesn't leak out from there.
Another possibility is a hybrid approach. Have only the lookup codepath
return ERETRYLOOKUP to indicate that the fs wants to retry more than
once. Once you have a pointer to the sb, then you can look at the FS_*
flag and use that to indicate that you want to retry on an ESTALE
return.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
