On Thu, 2012-12-13 at 22:06 -0500, Jeff Layton wrote:
> 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.
At this point, I don't care. My argument is that I haven't seen a SINGLE
instance where this warning has led to the discovery of a positive case.
Every single stack dump that I've seen so far has been a false negative,
which, as far as I'm concerned, should be considered a regression.
Forgive me for being pissed off...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
