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,
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
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
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
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
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) {
>>
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
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
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.
>>
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
Namjae Jeon linkinj...@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
OGAWA Hirofumi hirof...@mail.parknet.co.jp writes:
Namjae Jeon linkinj...@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
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
OGAWA Hirofumi hirof...@mail.parknet.co.jp writes:
Namjae Jeon linkinj...@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
Namjae Jeon linkinj...@gmail.com 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
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com 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) {
Namjae Jeon linkinj...@gmail.com 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
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com 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().
Namjae Jeon linkinj...@gmail.com writes:
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com 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
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
I see. fileid seems to be stat.ino on nfsd4. inode-i_ino is actually
just a hash key of inode hash
On Mon, Sep 24, 2012 at 09:32:00PM +0900, OGAWA Hirofumi wrote:
Namjae Jeon linkinj...@gmail.com writes:
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
I see. fileid seems to be stat.ino on nfsd4. inode-i_ino is actually
just a hash key
J. Bruce Fields bfie...@fieldses.org 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 Tue, Sep 25, 2012 at 01:16:45AM +0900, OGAWA Hirofumi wrote:
J. Bruce Fields bfie...@fieldses.org 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
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 bfie...@fieldses.org:
On Tue, Sep 25, 2012 at 01:16:45AM +0900, OGAWA Hirofumi wrote:
J. Bruce
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
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
2012/9/22, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com 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,
Namjae Jeon linkinj...@gmail.com 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
2012/9/24, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com 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.
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 =
Namjae Jeon linkinj...@gmail.com 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 =
From: Namjae Jeon
All the files on a FAT partition have an on-disk directory entry.
The location of these entries, i_pos, is unique and is constructed by
the fat_make_i_pos() function.We can use this as the inode number making
it persistent across remounts.
Signed-off-by: Namjae Jeon
From: Namjae Jeon namjae.j...@samsung.com
All the files on a FAT partition have an on-disk directory entry.
The location of these entries, i_pos, is unique and is constructed by
the fat_make_i_pos() function.We can use this as the inode number making
it persistent across remounts.
Signed-off-by:
36 matches
Mail list logo
