On Thu, 13 Dec 2012 21:22:26 +0000 "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2012-12-13 at 21:07 +0000, Al Viro wrote: > > On Thu, Dec 13, 2012 at 02:45:18PM +0000, Myklebust, Trond wrote: > > > > > You mean aside from the fact that sb->s_remove_count remains a racy > > > piece of crap that serves no good purpose for NFS, and yet will continue > > > to give us grief? > > > > As opposed to scanning the list of opened files? > > For what information? sb->s_remove_count tells you nothing new about the > state of the NFS filesystem. > > This whole "check for nlink == 0" thing is at best a heuristic, since > the file may persist or disappear on the server independently of > whatever we may think about the value of inode->i_nlink. Setting sirens > to blare and angels to sing when we get it wrong (as we often do) is > just pointless... > So...why do drop_nlink at all in NFS (or other similar filesystems like CIFS)? In principle, it seems like we ought to just mark the attribute cache invalid and assume that we'll pick up the nlink change when we next attempt to revalidate the inode. On that next attempt, we might find it stale, but that's something we already have to deal with. -- 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
