On Fri, 2012-12-14 at 07:51 -0500, Jeff Layton wrote:
> OTOH, there is at least a minor problem here with letting i_nlink
> underflow. When we finally get around to iput_final, generic_drop_inode
> is going to return false and we're going to end up with the inode
> lingering in the cache longer than it really should. Presumably memory
> pressure will eventually push it out, but it would be better not to
> have to wait for that.
As I said, the whole nlink test thing is a heuristic on NFS. Just
because we think we've successfully sent a REMOVE to the server, it
doesn't mean that file has actually been deleted. REMOVE refers to the
file by name, so there is plenty of opportunity for the server to play
tricks on us. I'm assuming that is what is happening in your Fedora bug
reports.
As far as we're concerned, the only reliable indicator that a file has
been deleted is when the server starts replying ESTALE to that
filehandle.
> I'll also note that we call nfs_drop_nlink to decrement i_nlink
> everywhere else aside from this call site. What makes nfs_dentry_iput
> special in this regard?
nfs_dentry_iput() is not special, but the test in nfs_drop_nlink() is.
If we're not able to track inode->i_nlink, then why is forcing an inode
eviction more correct than not doing so?
--
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�����٥
