2012/9/24, OGAWA Hirofumi <hirof...@mail.parknet.co.jp>: > Namjae Jeon <linkinj...@gmail.com> writes: > >>> This means - which code returns error? >> Sorry, My explanation may be insufficient. >> >> nfs_update_inode()-> on NFS client >> if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != >> fattr->fileid) { >> printk(KERN_ERR "NFS: server %s error: fileid changed\n" >> "fsid %s: expected fileid 0x%Lx, got 0x%Lx\n", >> NFS_SERVER(inode)->nfs_client->cl_hostname, >> inode->i_sb->s_id, (long long)nfsi->fileid, >> (long long)fattr->fileid); >> goto out_err; >> } >> >> that the problem in that case will occur with the file handle on NFS >> Client because the file handle on NFS client is still referring the >> old inode number even though the i-pos is same > > I see. fileid seems to be stat.ino on nfsd4. inode->i_ino is actually > just a hash key of inode hash (exception is only in audit, iirc). > > So, what happens if we set "stat->ino = i_pos" on fat_getattr(). > > int fat_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat > *stat) > { > struct inode *inode = dentry->d_inode; > generic_fillattr(inode, stat); > stat->blksize = MSDOS_SB(inode->i_sb)->cluster_size; > if (opts->nfs == FAT_NFS_LIMITED) { > /* Use i_pos for ino. This is used as fileid of nfs. */ > stat->ino = MSDOS_SB(inode->i_sb)->i_pos; > } > return 0; > } Okay, Thanks for your help. I will share the result after checking.
> -- > OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/