If it is a write (at least nfsv4) we don't have this issue right? We will have an open, the open will have a dentry in cache so we will have an inode num cached. On Tue, Mar 1, 2011 at 2:31 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Tue, 1 Mar 2011 14:11:32 -0600 > Steve French <smfrench@xxxxxxxxx> wrote: > >> I vaguely remember that the same problem can occur with nfsd on a >> local file system and that nfs clients have to be able to recover from >> ESTALE (e.g. lookup/delete/create/lookup would fail with ESTALE >> otherwise). Don't clients handle ESTALE by relooking up the file ala >> >> http://lwn.net/Articles/272684/ >> > > In the case of writeback, what pathname will you use? The client just > has an inode and that inode has a filehandle. The path hasn't been > dealt with since the open(). > > Even if it did want to retry a lookup, it's certainly possible that the > file has been renamed on the server or by another client. If that's the > case, the NFS client will have no valid path that it can reuse anyway. > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > -- Thanks, Steve -- 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
