On Tue, Mar 01, 2011 at 02:38:27PM -0600, Steve French wrote: > On Tue, Mar 1, 2011 at 2:34 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Tue, Mar 01, 2011 at 02:11:32PM -0600, Steve French wrote: > >> I vaguely remember that the same problem can occur with nfsd on a > >> local file system > > > > Not true; as I've said, exportable local filesystems know how to look up > > a file on disk by filehandle. > > > >> and that nfs clients have to be able to recover from > >> ESTALE (e.g. lookup/delete/create/lookup would fail with ESTALE > >> otherwise). > > > > It is true, however, that there are some *other* cases when a server can > > return ESTALE. ÂIn those cases (such as the one Peter Staubach discusses > > in more detail at http://lwn.net/Articles/272684/) there may be some > > recovery that a client might reasonably attempt. > > > > Alas, no client can be expected to recover from ESTALE errors on an > > opened file--those will just be passed on to the application. > > If this is v4 (only) wouldn't we always have an open->dentry in cache? That's correct, but only as long as the server is running. We need reboot recovery to work as well. Also: - NFSv4 uptake is still rather small as far as I know, so the v3 behavior is important - We don't currently have any way to export cifs as v4 only. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
