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

[Namjae Jeon]

2012/9/24, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
> Namjae Jeon <linkinjeon@xxxxxxxxx> writes:
>
>>> I think we don't need this. Because FH and ino is not necessary to have
>>> relation.
>>>
>>> Can we re-introduce ->encode_fh() handler, and export i_pos again?  With
>>> this, I think we can get i_pos correctly. Otherwise, ino may not contain
>>> all bits of i_pos.
>> I already tried to fix this issue using encode_fh without stable ino
>> before.
>> But I reached conclusion that we should use stable inode number.
>>
>> e.g. If we rebuild inode number using i_pos of fh, inode number is
>> changed by i_unique.
>> And It is not match with inode number of FH on NFS client. So estale
>> error will happen.
>
> 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.
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.

Thanks.
> --
> 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/