Hi, Since upgrading from 2.6.39-ish to 3.1-ish, and on 3.2.5, we are seeing a lot of occurrences of Stale NFS file handle errors when accessing a mount whose NFSv3 source is a subdirectory of another mount point. For example, in this case: # mount | grep /shared 10.10.1.1:/storage/vg1/shared on /shared type nfs (rw,hard,intr,tcp,timeo=300,retrans=2,vers=3,addr=10.10.1.1) 10.10.1.1:/storage/vg1/shared/fp on /usr/local/fp type nfs (rw,hard,intr,tcp,timeo=300,retrans=2,vers=3,addr=10.10.1.1) When the issue occurs, the /shared mount point is fine as is /shared/fp, but "df" or "ls" or anything on /usr/local/fp will ESTALE. This somehow corrected itself while I was trying to gather information this time, but usually the d_ino returned by getdents() on the parent directory shows a different inode number than for /shared/fp. When this happens, I am unable to umount -f or umount -l /usr/local/fp (ESTALE), but I can actually umount /shared; umount /usr/local/fp; and mount -a, which seems to "fix" it. is this acting similar to a bind mount internally now and revalidation or something is breaking in this case? This is happening fairly often, so I will try to collect more info again next time. Simon- -- 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