2012/9/14, OGAWA Hirofumi :
> "J. Bruce Fields" writes:
>
>>> > Current -mm means the best-effort work only if inode cache is not
>>> > evicted. I.e. if there is no inode cache anymore on server, server
>>> > would return ESTALE. So I guess the behavior would not be stable
>>> > relatively.
>>> H
"J. Bruce Fields" writes:
>> > Current -mm means the best-effort work only if inode cache is not
>> > evicted. I.e. if there is no inode cache anymore on server, server
>> > would return ESTALE. So I guess the behavior would not be stable
>> > relatively.
>> Hi OGAWA.
>> Sorry for late response.
On Thu, Sep 13, 2012 at 11:24:30PM +0900, Namjae Jeon wrote:
> 2012/9/13, OGAWA Hirofumi :
> > "J. Bruce Fields" writes:
> >
> >>> >> Grepping around... Documentation/sysctl/vm.txt mentions a
> >>> >> vfs_cache_pressure parameter.
> >>> >> Yeah. And dirty hack will be possible to adjust sb->s_shri
2012/9/13, OGAWA Hirofumi :
> "J. Bruce Fields" writes:
>
>>> >> Grepping around... Documentation/sysctl/vm.txt mentions a
>>> >> vfs_cache_pressure parameter.
>>> >> Yeah. And dirty hack will be possible to adjust sb->s_shrink.batch.
>>> > I am worrying if it could lead to OOM condition on embedd
"J. Bruce Fields" writes:
>> >> Grepping around... Documentation/sysctl/vm.txt mentions a
>> >> vfs_cache_pressure parameter.
>> >> Yeah. And dirty hack will be possible to adjust sb->s_shrink.batch.
>> > I am worrying if it could lead to OOM condition on embedded
>> > system(short memory(DRAM) a
On Thu, Sep 13, 2012 at 05:33:02PM +0900, OGAWA Hirofumi wrote:
> Namjae Jeon writes:
>
> >> I see. So, client can't solve the ESTALE if inode cache was evicted,
> >> right? (without application changes)
> >
> > There can be situation where we may get not only ESTALE but EIO also.
> >
> > For exa
Namjae Jeon writes:
>> I see. So, client can't solve the ESTALE if inode cache was evicted,
>> right? (without application changes)
>
> There can be situation where we may get not only ESTALE but EIO also.
>
> For example,
> ---
> fd = open(“foo.txt”);
> while (1) {
>
> >> -> ESTALE will be returned -> discard old FH -> restart from LOOKUP ->
> >> make cached inode -> use returned new FH.
> >>
> >> Yeah, I know this is unstable (there is no perfect solution for now),
> >
> > You may end up with a totally different file, of course:
> >
> > client:
"J. Bruce Fields" writes:
> As another server-side workaround: maybe they could try tuning the inode
> caching to make eviction less likely?
>
> Grepping around... Documentation/sysctl/vm.txt mentions a
> vfs_cache_pressure parameter.
Yeah. And dirty hack will be possible to adjust sb->s_shrink
On Thu, Sep 13, 2012 at 02:38:11AM +0900, OGAWA Hirofumi wrote:
> "J. Bruce Fields" writes:
>
> >> On other view (as server side solution), we are thinking there is
> >> possible to make the stable filehandle on FAT if we disabled some
> >> operations (e.g. rename(), unlink()) which change inode
"J. Bruce Fields" writes:
>> On other view (as server side solution), we are thinking there is
>> possible to make the stable filehandle on FAT if we disabled some
>> operations (e.g. rename(), unlink()) which change inode location in FAT.
>>
>> Yes, it would be stable, but supporting limited op
On Thu, Sep 13, 2012 at 02:03:51AM +0900, OGAWA Hirofumi wrote:
> "J. Bruce Fields" writes:
>
> >> > Supposing, the server/client state is after cold boot, and client try to
> >> > rename at first without any cache on client/server.
> >> >
> >> > Even if this state, does the server return ESTALE?
"J. Bruce Fields" writes:
>> > Supposing, the server/client state is after cold boot, and client try to
>> > rename at first without any cache on client/server.
>> >
>> > Even if this state, does the server return ESTALE? If it doesn't return
>> > ESTALE, I can't understand why it is really unfix
On Wed, Sep 12, 2012 at 11:12:56PM +0900, Namjae Jeon wrote:
> 2012/9/12 OGAWA Hirofumi :
> > Namjae Jeon writes:
> >
> I think that it is unfixable because we can not know i_pos of inode
> changed by rename.
> And even though we know it, there is no rebuild inode routine in -mm.
>
2012/9/12 OGAWA Hirofumi :
> Namjae Jeon writes:
>
I think that it is unfixable because we can not know i_pos of inode
changed by rename.
And even though we know it, there is no rebuild inode routine in -mm.
And It even can not fix in our patches.
>>>
> And are you tried ht
Namjae Jeon writes:
>>> I think that it is unfixable because we can not know i_pos of inode
>>> changed by rename.
>>> And even though we know it, there is no rebuild inode routine in -mm.
>>> And It even can not fix in our patches.
>>
And are you tried https://lkml.org/lkml/2012/6/29/381 pa
2012/9/11 OGAWA Hirofumi :
> Namjae Jeon writes:
>
>>> Since rename() will be disabled on stable ino patches, this will be
>>> unfixable, so rather maybe it is worse.
>> Currently with our patchset : only rename issue (could not find any
>> correct approach to ignore this. If we do not update this
Namjae Jeon writes:
>> Since rename() will be disabled on stable ino patches, this will be
>> unfixable, so rather maybe it is worse.
> Currently with our patchset : only rename issue (could not find any
> correct approach to ignore this. If we do not update this immediately
> at i_pos change – i
2012/9/10, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> Yes, It is true(current VFAT of -mm tree is not stable). Although we
>> set lookupcache=none while mounting, ESTALE error can still occur in
>> rename case.
>> So there still remain ESTALE error issue from rename case on current -mm
>> tree.
Namjae Jeon writes:
> Yes, It is true(current VFAT of -mm tree is not stable). Although we
> set lookupcache=none while mounting, ESTALE error can still occur in
> rename case.
> So there still remain ESTALE error issue from rename case on current -mm tree.
> plz See the step as the following
>
On Sun, 2012-09-09 at 18:32 +0900, OGAWA Hirofumi wrote:
> What is your use case?
What Neil Brown refers to as a "general file access protocol" -
basically making a flash disk available to a small embedded network for
random-access file I/O.
The flash disk is required to interoperate with Wind
2012/9/9, OGAWA Hirofumi :
> OGAWA Hirofumi writes:
>
>> What is your use case? I'm assuming current NFS support of FAT
>> is still unstable behavior even with your patches. Is this true?
Hi. OGAWA.
Yes, It is true(current VFAT of -mm tree is not stable). Although we
set lookupcache=none while
OGAWA Hirofumi writes:
> What is your use case? I'm assuming current NFS support of FAT is not
> unstable behavior even with your patches. Is this true?
s/is not unstable/is still unstable/
--
OGAWA Hirofumi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
"Steven J. Magnani" writes:
> On Fri, 2012-09-07 at 16:01 +0900, Namjae Jeon wrote:
>> Hi. OGAWA.
>>
>> I checked read-only option for export on FAT.
>> I think that there are 3 approaches as mentioned below.
>>
>> 1. As per the current scenario – user already has the option of
>> setting ‘ro’
On Fri, 2012-09-07 at 16:01 +0900, Namjae Jeon wrote:
> Hi. OGAWA.
>
> I checked read-only option for export on FAT.
> I think that there are 3 approaches as mentioned below.
>
> 1. As per the current scenario – user already has the option of
> setting ‘ro’ in /etc/exports – so that can also be
Hi. OGAWA.
I checked read-only option for export on FAT.
I think that there are 3 approaches as mentioned below.
1. As per the current scenario – user already has the option of
setting ‘ro’ in /etc/exports – so that can also be used to make it
read-only.
2. Forcefully set to “read-only”
2012/9/6 OGAWA Hirofumi :
> Namjae Jeon writes:
>
In this long discusstion about the FAT acceptance over NFS, our belief
is still that the objective should be to reduce errors as much as
possible and then if there are certain scenarios - at least that could
be highlighted as a
Namjae Jeon writes:
>>> In this long discusstion about the FAT acceptance over NFS, our belief
>>> is still that the objective should be to reduce errors as much as
>>> possible and then if there are certain scenarios - at least that could
>>> be highlighted as a limitation in Documentation inste
2012/9/5 OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> In this long discusstion about the FAT acceptance over NFS, our belief
>> is still that the objective should be to reduce errors as much as
>> possible and then if there are certain scenarios - at least that could
>> be highlighted as a limitati
Namjae Jeon writes:
> In this long discusstion about the FAT acceptance over NFS, our belief
> is still that the objective should be to reduce errors as much as
> possible and then if there are certain scenarios - at least that could
> be highlighted as a limitation in Documentation instead of co
2012/9/5, Al Viro :
> On Wed, Sep 05, 2012 at 12:57:44AM +0900, Namjae Jeon wrote:
>> 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
On Wed, Sep 05, 2012 at 12:57:44AM +0900, Namjae Jeon wrote:
> 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
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
peristent across remounts.
Signed-off-by: Namjae Jeon
Signed-off-
33 matches
Mail list logo
