lkml.org 
[lkml]   [2012]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3 2/5] fat: allocate persistent inode numbers
From
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>
>


\
 
 \ /
  Last update: 2012-09-24 09:41    [W:0.057 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site