Messages in this thread | | | Date | Mon, 24 Sep 2012 16:02:39 +0900 | Subject | Re: [PATCH v3 2/5] fat: allocate persistent inode numbers | From | Namjae Jeon <> |
| |
2012/9/24, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>: > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes: > >> Namjae Jeon <linkinjeon@gmail.com> writes: >> >>>> What is problem if i_ino + i_generation is not match? I think, even if >>>> those didn't match, i_pos in FH should resolve issue, no? >>> No, It can not resolve issue. >>> in NFS file handle, there is a reference to the current inode number. >>> So, if by eviction that is changed - that it will results in "file id >>> changed" error. >> >> Who returns error? > > 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
Thanks.
> >>> even though using the i_pos we can reconstruct and get the INODE on >>> the Server, but the NFS handle is no more valid. As the inode number >>> is also changed, iunique() for the file will result in different >>> number this time. > > -- > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> >
| |