|
The handles appear in wireshark is the same as in the /proc/net/rpc/nfsd.fh/content info
but there no corresponding directory path. just like this:
# * 6 0x06fd0000000000000000000000000000
root@Dahua_Storage:~# cat /proc/net/rpc/nfsd.fh/content
#domain fsidtype fsid [path] * 6 0x00fd0000000000000000000000000000 /mnt/storage_pool/testnfs00 * 6 0x03fd0000000000000000000000000000 /mnt/storage_pool/testnfs03 * 6 0x02fd0000000000000000000000000000 /mnt/storage_pool/testnfs02 * 6 0x01fd0000000000000000000000000000 /mnt/storage_pool/testnfs01 # * 6 0x06fd0000000000000000000000000000 * 6 0x05fd0000000000000000000000000000 /mnt/storage_pool/testnfs05 * 6 0x04fd0000000000000000000000000000 /mnt/storage_pool/testnfs04 # * 6 0x09fd0000000000000000000000000000 # * 6 0x08fd0000000000000000000000000000 # * 6 0x07fd0000000000000000000000000000 more info, this problem happens when rebooting the storage server while the nfs clients is still accessing the mounting points.
> Date: Tue, 24 Jan 2012 12:58:26 -0500 > From: hch@xxxxxxxxxxxxx > To: ygq51@xxxxxxxxxxx > Subject: Re: xfs: validate inode numbers in file handles correctly--NFS Stale File Handle Again > CC: hch@xxxxxxxxxxxxx; linux-xfs@xxxxxxxxxxx; pengxihan@xxxxxxxxx > > On Wed, Jan 04, 2012 at 10:20:31AM +0800, yangguoquan wrote: > > > > Yes, They are mount points. > > > > /dev/mapper/storage_pool-testnfs00 on /mnt/storage_pool/testnfs00 type xfs (rw) > > In that case I really have no idea. Did you make sure you no > outstanding "old" filehandles before the fix on clients? How do the > handles look in wireshark traces? > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs |
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
