Re: [PATCH v3 2/5] fat: allocate persistent inode numbers

[Namjae Jeon]

2012/9/24, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> writes:
>
>> Namjae Jeon <linkinjeon@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/