xfs: validate inode numbers in file handles correctly--NFS Stale File Handle Again
yangguoquan
ygq51 at hotmail.com
Thu Dec 29 03:19:55 CST 2011
NFS Stale File Handle Again, But this happens when mount operation not during accessing file or directory.
My /etc/exports file:
/mnt/storage_pool/testnfs00 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs01 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs02 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs03 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs04 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs05 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs06 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs07 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs08 *(rw,sync,no_root_squash)
/mnt/storage_pool/testnfs09 *(rw,sync,no_root_squash)
Proc info as follows:
root at Dahua_Storage:~# cat /proc/net/rpc/nfsd
rc 0 5428 3350
fh 600 0 0 0 0
io 0 1195819008
th 8 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
ra 32 0 0 0 0 0 0 0 0 0 0 0
net 8779 1 8771 1
rpc 8778 0 0 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 1 819 0 840 1432 0 0 4587 12 0 0 0 829 0 0 0 0 37 10 0 0 210
proc4 2 0 0
proc4ops 59 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
root at Dahua_Storage:~# cat /proc/net/rpc/nfsd.export/content
#path domain(flags)
/mnt/storage_pool/testnfs02 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd02:00000000:00000000:00000000)
/mnt/storage_pool/testnfs04 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd04:00000000:00000000:00000000)
/mnt/storage_pool/testnfs00 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd00:00000000:00000000:00000000)
/mnt/storage_pool/testnfs05 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd05:00000000:00000000:00000000)
/mnt/storage_pool/testnfs01 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd01:00000000:00000000:00000000)
/mnt/storage_pool/testnfs03 *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=0000fd03:00000000:00000000:00000000)
root at Dahua_Storage:~# cat /proc/net/rpc/nfsd.fh/
channel content flush
root at 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
When I mount "/mnt/storage_pool/testnfs07" which does not appear in the proc info , problem happens, I can not even mount from local machine.
More info:
1. I use tcpdump and find that STALE returns when FSINFO call during mount procdure, please check the attached screenshot.
2. I debug nfsd, and find that FSINFO fail stack:
cache_check() return -ENOENT or -EAGAIN
exp_find_key()
exp_find()
rqst_exp_find()
nfsd_set_fh_dentry()
fh_verify()
nfsd3_proc_fsinfo()
Please help me, my kernel is still 2.6.35.6.
Looking forward for your reply!
Thanks!
From: ygq51 at hotmail.com
To: hch at infradead.org
Subject: RE: xfs: validate inode numbers in file handles correctly
Date: Sat, 3 Dec 2011 17:56:20 +0800
CC: linux-xfs at oss.sgi.com; pengxihan at gmail.com
I have tried this patch, And problem resolved!
Thank you for your help!
> Date: Mon, 28 Nov 2011 06:19:47 -0500
> From: hch at infradead.org
> To: ygq51 at hotmail.com
> Subject: Re: xfs: validate inode numbers in file handles correctly
> CC: linux-xfs at oss.sgi.com; pengxihan at gmail.com
>
> Guoquan and hank,
>
> are you using 32-bit or 64-bit kernels? I just noticed we have a
> problem with exporting 64-bit inodes on 32-bit kernel because the
> VFS i_ino field is just 32-bits long. The patch below would fix
> that issue.
>
> --- xfs.orig/fs/xfs/linux-2.6/xfs_export.c 2011-11-28 12:11:08.923630697 +0100
> +++ xfs/fs/xfs/linux-2.6/xfs_export.c 2011-11-28 12:13:21.766244360 +0100
> @@ -61,6 +61,8 @@ xfs_fs_encode_fh(
> struct fid *fid = (struct fid *)fh;
> struct xfs_fid64 *fid64 = (struct xfs_fid64 *)fh;
> struct inode *inode = dentry->d_inode;
> + struct inode *parent;
> + struct xfs_inode *ip = XFS_I(inode);
> int fileid_ type;
> int len;
>
> @@ -98,22 +100,24 @@ xfs_fs_encode_fh(
> switch (fileid_type) {
> case FILEID_INO32_GEN_PARENT:
> spin_lock(&dentry->d_lock);
> - fid->i32.parent_ino = dentry->d_parent->d_inode->i_ino;
> - fid->i32.parent_gen = dentry->d_parent->d_inode->i_generation;
> + parent = dentry->d_parent->d_inode;
> + fid->i32.parent_ino = XFS_I(parent)->i_ino;
> + fid->i32.parent_gen = parent->i_generation;
> spin_unlock(&dentry->d_lock);
> /*FALLTHRU*/
> case FILEID_INO32_GEN:
> - fid->i32.ino = inode->i_ino;
> + fid->i32.ino = ip->i_ino;
> fid->i32.gen = inode->i_generation;
> break;
> case FILEID_INO32_GEN_PARENT | XFS_FILEID_TYPE_64FLAG:
> spin_lock(&dentry->d_lock);
> - fid64->parent_ino = dentry->d_parent->d_inode->i_ino;
> - fid64->parent_gen = dentry->d_parent->d_inode->i_generation;
> + parent = dentry->d_parent->d_inode;
> + fid64->parent_ino = XFS_I(parent)->i_ino;
> + fid64->parent_gen = parent->i_generation;
> spin_unlock(&dentry->d_lock);
> /*FALLTHRU*/
> case FILEID_INO32_GEN | XFS_FILEID_TYPE_64FLAG:
> - fid64->ino = inode->i_ino;
> + fid64->ino = ip->i_ino;
> fid64->gen = inode->i_generation;
> break;
> }
>
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________ xfs mailing list xfs at oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20111229/49f0eafc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stale.JPG
Type: image/jpeg
Size: 146524 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20111229/49f0eafc/attachment.jpeg>
More information about the xfs
mailing list