Hi OGAWA.
It works fine. there is no estale error while memory reclaim.
I will make patchset again as review comment and your suggestion
(encode_fh, fat_getattr).
Thanks!
2012/9/25, J. Bruce Fields :
> On Tue, Sep 25, 2012 at 01:16:45AM +0900, OGAWA Hirofumi wrote:
>> "J. Bruce Fields" writes:
On Tue, Sep 25, 2012 at 01:16:45AM +0900, OGAWA Hirofumi wrote:
> "J. Bruce Fields" writes:
>
> >> > There is some unclear thing.
> >> > When I see first mail, I think maybe you don't want to use i_pos for
> >> > inode->ino.
> >> > FAT allocate inode->ino from i_unique on server side and If NFS
"J. Bruce Fields" writes:
>> > There is some unclear thing.
>> > When I see first mail, I think maybe you don't want to use i_pos for
>> > inode->ino.
>> > FAT allocate inode->ino from i_unique on server side and If NFS client
>> > use i_pos for inode->ino in fat_get_attr, inode numbers on each
On Mon, Sep 24, 2012 at 09:32:00PM +0900, OGAWA Hirofumi wrote:
> Namjae Jeon writes:
>
> > 2012/9/24, OGAWA Hirofumi :
> >> Namjae Jeon writes:
> >>
> 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, iir
2012/9/24, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> 2012/9/24, OGAWA Hirofumi :
>>> Namjae Jeon writes:
>>>
> 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
Namjae Jeon writes:
> 2012/9/24, OGAWA Hirofumi :
>> Namjae Jeon writes:
>>
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().
2012/9/24, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>>> 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(struc
Namjae Jeon writes:
>> 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 *dentr
2012/9/24, OGAWA Hirofumi :
> Namjae Jeon 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
Namjae Jeon 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\
2012/9/24, OGAWA Hirofumi :
> OGAWA Hirofumi writes:
>
>> Namjae Jeon 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 referenc
OGAWA Hirofumi writes:
> Namjae Jeon 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,
Namjae Jeon 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 -
2012/9/24, OGAWA Hirofumi :
> Namjae Jeon 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 contai
Namjae Jeon 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
2012/9/22, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> -inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
>> +if (MSDOS_SB(sb)->options.nfs == FAT_NFS_LIMITED)
>> +inode->i_ino = i_pos;
>> +else
>> +inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
>> inode->i_version
Namjae Jeon writes:
> - inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
> + if (MSDOS_SB(sb)->options.nfs == FAT_NFS_LIMITED)
> + inode->i_ino = i_pos;
> + else
> + inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
> inode->i_version = 1;
> err = fat_fill_ino
17 matches
Mail list logo
