NetworkAppliance dedicated NFS servers have a snapshot capability that
allows for quick read-only access to past versions of files and
directories. They make this available via a hidden .snapshot directory
in every NFS directory. I say hidden because it does not show up via ls
(and readdir). So, "ls -a" does not show it, but "ls .snapshot" does
list its contents, which are things like hourly.0, nightly.2, weekly.1,
monthly.1, etc. The reason the directory is normally hidden is so that
recursive tar's and cp's do not descend into it.
Problem:
In 2.1.125 SMP and 2.0.35 UP, I see the following behavior:
% cd ~zue
% ls .snapshot
hourly.0 hourly.1 hourly.2 hourly.3 ...
% ls .snapshot/hourly.0
ls: .snapshot/hourly.0: Input/output error
% ls .snapshot
ls: .snapshot: Input/output error
As you can see, the ls that worked the first time no longer works. I
see the following entries in /var/log/messages:
Oct 29 19:49:24 sls-dell-27 kernel: nfs_free_dentries: found users/zue, d_count=3, hashed=1
Oct 29 19:49:24 sls-dell-27 kernel: __nfs_fhget: inode 3763684 still busy, i_count=2
Oct 29 19:49:24 sls-dell-27 kernel: __nfs_fhget: killing users/zue filehandle
I've also seen messages about dud filehandles. At this point, the only
way to get that directory working again is to umount/mount the
filesystem. Other directories are not affected as far as I can tell,
but this one is stuck.
Is there more information that would be useful for debugging? Perhaps
capturing the NFS packets? I'm not sure how to proceed, and I'm not
knowledgable about kernel debugging.
--Lee Hetherington
<ilh@sls.lcs.mit.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/