On Mon, 2012-12-17 at 08:08 -0500, Jeff Layton wrote: +AD4- On Fri, 14 Dec 2012 18:22:27 +-0000 +AD4- +ACI-Myklebust, Trond+ACI- +ADw-Trond.Myklebust+AEA-netapp.com+AD4- wrote: +AD4- +AD4- +AD4- On Fri, 2012-12-14 at 07:51 -0500, Jeff Layton wrote: +AD4- +AD4- +AD4- OTOH, there is at least a minor problem here with letting i+AF8-nlink +AD4- +AD4- +AD4- underflow. When we finally get around to iput+AF8-final, generic+AF8-drop+AF8-inode +AD4- +AD4- +AD4- is going to return false and we're going to end up with the inode +AD4- +AD4- +AD4- lingering in the cache longer than it really should. Presumably memory +AD4- +AD4- +AD4- pressure will eventually push it out, but it would be better not to +AD4- +AD4- +AD4- have to wait for that. +AD4- +AD4- +AD4- +AD4- As I said, the whole nlink test thing is a heuristic on NFS. Just +AD4- +AD4- because we think we've successfully sent a REMOVE to the server, it +AD4- +AD4- doesn't mean that file has actually been deleted. REMOVE refers to the +AD4- +AD4- file by name, so there is plenty of opportunity for the server to play +AD4- +AD4- tricks on us. I'm assuming that is what is happening in your Fedora bug +AD4- +AD4- reports. +AD4- +AD4- +AD4- +AD4- As far as we're concerned, the only reliable indicator that a file has +AD4- +AD4- been deleted is when the server starts replying ESTALE to that +AD4- +AD4- filehandle. +AD4- +AD4- +AD4- +AD4- +AD4- I'll also note that we call nfs+AF8-drop+AF8-nlink to decrement i+AF8-nlink +AD4- +AD4- +AD4- everywhere else aside from this call site. What makes nfs+AF8-dentry+AF8-iput +AD4- +AD4- +AD4- special in this regard? +AD4- +AD4- +AD4- +AD4- nfs+AF8-dentry+AF8-iput() is not special, but the test in nfs+AF8-drop+AF8-nlink() is. +AD4- +AD4- If we're not able to track inode-+AD4-i+AF8-nlink, then why is forcing an inode +AD4- +AD4- eviction more correct than not doing so? +AD4- +AD4- +AD4- +AD4- The patchset you sent after the above seems basically correct to me, +AD4- but since you asked... +AD4- +AD4- It's hard to generalize on server behavior, but if a server sends us an +AD4- attributes with i+AF8-nlink +AD0APQ- 0, it seems unlikely to go positive again. +AD4- For most servers, that means that the inode is now unreachable via +AD4- LOOKUP. Therefore, once d+AF8-iput is called we won't have a way to get to +AD4- the inode again. Forcing it out of the cache seems like the right +AD4- thing to do in that case. We don't know what the server's idea of inode-+AD4-i+AF8-nlink is. The REMOVE operation doesn't return any information about the target inode, so we were just manipulating our cached values. +AD4- A negative i+AF8-nlink OTOH makes no sense at all. If our actions are going +AD4- to make that happen then we ought to take steps to prevent it. We now only manipulate the cached value if we want the VFS to forget the inode. Otherwise, we just mark the inode attributes for revalidation. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust+AEA-netapp.com www.netapp.com -- 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
