On Thu, 2 Aug 2012 19:29:14 -0700 (PDT) Andrei Warkentin <awarkentin@xxxxxxxxxx> wrote: > ----- Original Message ----- > > From: "Ed Goggin" <egoggin@xxxxxxxxxx> > > To: linux-nfs@xxxxxxxxxxxxxxx > > Sent: Thursday, August 2, 2012 9:57:58 PM > > Subject: stale or not stale > > > > > > It seems that nfsd can return reply attributes with a link count of > > zero but without an NFS3ERR_STALE status. We've seen this actually > > happen for a write request to a file with a single link that is > > concurrently being removed without NLM lock protection. What is the > > proper behavior here? > > I think it would be worthwhile to add here that the the remove was not concurrent with the write, and at the time of the NFS write a new file with the same name existed, yet fh decoding picked up the old inode instead of reporting -ESTALE. FS was ext4. > > In fact seen two things happen - n_link = 0 and n_link = 1, and in both cases we knew the file was unlink()ed and re-creat()ed. > That's entirely valid behavior. ESTALE from the server is its way of saying: "I don't recognize that filehandle". It can't figure out how to match that filehandle to an inode. An i_nlink count of 0 means that there are no more hardlinks attached to the inode. It's deleted from the namespace, but the inode still exists until there are no more i_count references held on it. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
