If you use NFSv4 to "mount server:/foo/bar /mnt", then "rm -r" /foo/bar on the server, then accesses to /mnt will naturally return ESTALE. Unfortunately "umount /mnt" will also return ESTALE and leave the stale directory mounted. Adding "-l" or "-f" to "umount" doesn't help. The problem is that nfs_lookup_revalidate fails. As the mountpoint is never not accessed by a lookup (after the initial mount) it seems a bit pointless calling d_revalidate in this case ... by maybe not. I can make the problem go away by testing for LOOKUP_JUMP and having nfs_lookup_revalidate never fail if that flag it set (for a directory). The resulting patch is: --- fs/nfs/dir.c | 7 +++++++ 1 file changed, 7 insertions(+) --- linux-3.0-SLE11-SP2.orig/fs/nfs/dir.c +++ linux-3.0-SLE11-SP2/fs/nfs/dir.c @@ -1183,6 +1183,13 @@ out_zap_parent: goto out_valid; if (dentry->d_flags & DCACHE_DISCONNECTED) goto out_valid; + if (flags & LOOKUP_JUMPED) + /* Didn't use a name to get here, so saying + * the name is invalid is pointless. + * This allows "umount" to succeed on a + * STALE mountpoint. + */ + goto out_valid; shrink_dcache_parent(dentry); } d_drop(dentry); However I cannot easily tell if this is an elegant solution of an ugly hack, and am hoping that someone who understands revalidation and LOOKUP_JUMPED better than I (who only discovered the latter today) could provide advice. Al? Trond? Should I make this into a formal patch submission, or is there a better way? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
