2013/1/28, OGAWA Hirofumi :
> Namjae Jeon writes:
>
Although checking several routines to check hang case you said, I
didn't find anything.
And There is no any race on test result also. Am I missing something ?
Let me know your opinion.
>>>
>>> Hm, it's read-only. So, there
Namjae Jeon writes:
>>> Although checking several routines to check hang case you said, I
>>> didn't find anything.
>>> And There is no any race on test result also. Am I missing something ?
>>> Let me know your opinion.
>>
>> Hm, it's read-only. So, there may not be race for now, I'm sure there
Namjae Jeon linkinj...@gmail.com writes:
Although checking several routines to check hang case you said, I
didn't find anything.
And There is no any race on test result also. Am I missing something ?
Let me know your opinion.
Hm, it's read-only. So, there may not be race for now, I'm sure
2013/1/28, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
Although checking several routines to check hang case you said, I
didn't find anything.
And There is no any race on test result also. Am I missing something ?
Let me know your opinion.
Hm, it's
2013/1/26, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> 2013/1/20, OGAWA Hirofumi :
>>> Namjae Jeon writes:
>>>
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
>>>
>>> Looks like good as initial. Clean and shorter.
>>>
>>> Next is, we
2013/1/26, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
2013/1/20, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Namjae Jeon writes:
> 2013/1/20, OGAWA Hirofumi :
>> Namjae Jeon writes:
>>
>>> We rewrite patch as your suggestion using dummy inode. Would please
>>> you review below patch code ?
>>
>> Looks like good as initial. Clean and shorter.
>>
>> Next is, we have to think about race. I.e. if real
Namjae Jeon linkinj...@gmail.com writes:
2013/1/20, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Looks like good as initial. Clean and shorter.
Next
2013/1/20, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> We rewrite patch as your suggestion using dummy inode. Would please
>> you review below patch code ?
>
> Looks like good as initial. Clean and shorter.
>
> Next is, we have to think about race. I.e. if real inode was made, what
> happens? Is
2013/1/20, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Looks like good as initial. Clean and shorter.
Next is, we have to think about race. I.e. if
Namjae Jeon writes:
> We rewrite patch as your suggestion using dummy inode. Would please
> you review below patch code ?
Looks like good as initial. Clean and shorter.
Next is, we have to think about race. I.e. if real inode was made, what
happens? Is there no race?
Thanks.
> Subject:
Namjae Jeon linkinj...@gmail.com writes:
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Looks like good as initial. Clean and shorter.
Next is, we have to think about race. I.e. if real inode was made, what
happens? Is there no race?
Thanks.
>
> BTW, fat_search_long() was wrong as similar function. Actually it would
> be fat_scan(), because we don't care longname entry.
Hi OGAWA.
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Thanks.
BTW, fat_search_long() was wrong as similar function. Actually it would
be fat_scan(), because we don't care longname entry.
Hi OGAWA.
We rewrite patch as your suggestion using dummy inode. Would please
you review below patch code ?
Thanks.
2012/12/21, OGAWA Hirofumi :
> Namjae Jeon writes:
>
Hm, start with copy of fat_search_long() and refactoring it. With it,
we
will be able to avoid the fixed bugs.
After that, we might be able to merge those somehow. Well, I'm not
pretty sure without doing it
OGAWA Hirofumi writes:
> Namjae Jeon writes:
>
>>> Yes, we can't use fat_search_long() as is, of course. However, we can
>>> share the basic algorithm and code.
>>>
>>> The both are doing,
>>>
>>> 1) traverse the blocks chained by ->i_start.
>>> 2) get the record (dirent) from blocks.
>>> 3)
Namjae Jeon writes:
>> Yes, we can't use fat_search_long() as is, of course. However, we can
>> share the basic algorithm and code.
>>
>> The both are doing,
>>
>> 1) traverse the blocks chained by ->i_start.
>> 2) get the record (dirent) from blocks.
>> 3) check the detail of record
>>
>> The
Namjae Jeon writes:
>>> Hm, start with copy of fat_search_long() and refactoring it. With it, we
>>> will be able to avoid the fixed bugs.
>>>
>>> After that, we might be able to merge those somehow. Well, I'm not
>>> pretty sure without doing it actually though.
> Hi OGAWA.
>
> When we checked
Namjae Jeon linkinj...@gmail.com writes:
Hm, start with copy of fat_search_long() and refactoring it. With it, we
will be able to avoid the fixed bugs.
After that, we might be able to merge those somehow. Well, I'm not
pretty sure without doing it actually though.
Hi OGAWA.
When we
Namjae Jeon linkinj...@gmail.com writes:
Yes, we can't use fat_search_long() as is, of course. However, we can
share the basic algorithm and code.
The both are doing,
1) traverse the blocks chained by -i_start.
2) get the record (dirent) from blocks.
3) check the detail of record
The
OGAWA Hirofumi hirof...@mail.parknet.co.jp writes:
Namjae Jeon linkinj...@gmail.com writes:
Yes, we can't use fat_search_long() as is, of course. However, we can
share the basic algorithm and code.
The both are doing,
1) traverse the blocks chained by -i_start.
2) get the record (dirent)
2012/12/21, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
Hm, start with copy of fat_search_long() and refactoring it. With it,
we
will be able to avoid the fixed bugs.
After that, we might be able to merge those somehow. Well, I'm not
pretty sure
2012/12/20, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>>> Okay, We will check how we can consolidate the 2 paths to avoid any
>>> issue.
>> Hi OGAWA.
>>
>> On checking fat_search_long() logic, it is observed that it performs
>> name based lookup of the entries in a given directory.
>> In
2012/12/21, Namjae Jeon :
> 2012/12/20, OGAWA Hirofumi :
>> Namjae Jeon writes:
>>
Okay, We will check how we can consolidate the 2 paths to avoid any
issue.
>>> Hi OGAWA.
>>>
>>> On checking fat_search_long() logic, it is observed that it performs
>>> name based lookup of the entries
2012/12/21, Namjae Jeon linkinj...@gmail.com:
2012/12/20, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
Okay, We will check how we can consolidate the 2 paths to avoid any
issue.
Hi OGAWA.
On checking fat_search_long() logic, it is observed that it
2012/12/20, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
Okay, We will check how we can consolidate the 2 paths to avoid any
issue.
Hi OGAWA.
On checking fat_search_long() logic, it is observed that it performs
name based lookup of the entries in a
Namjae Jeon writes:
>> Okay, We will check how we can consolidate the 2 paths to avoid any issue.
> Hi OGAWA.
>
> On checking fat_search_long() logic, it is observed that it performs
> name based lookup of the entries in a given directory.
> In fat_get_parent(), we do not have such information
Namjae Jeon linkinj...@gmail.com writes:
Okay, We will check how we can consolidate the 2 paths to avoid any issue.
Hi OGAWA.
On checking fat_search_long() logic, it is observed that it performs
name based lookup of the entries in a given directory.
In fat_get_parent(), we do not have such
2012/12/5, Namjae Jeon :
> 2012/12/5, OGAWA Hirofumi :
>> Namjae Jeon writes:
>>
>> This became much better than before. However, we have to consolidate
>> the
>> code with fat_search_long() finally.
>>
>> E.g. this version is having the issue already fixed. If there is
>>
2012/12/5, Namjae Jeon linkinj...@gmail.com:
2012/12/5, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
This became much better than before. However, we have to consolidate
the
code with fat_search_long() finally.
E.g. this version is having the issue
2012/12/5, OGAWA Hirofumi :
> Namjae Jeon writes:
>
> This became much better than before. However, we have to consolidate
> the
> code with fat_search_long() finally.
>
> E.g. this version is having the issue already fixed. If there is
> corruption in fat cluster-chain,
Namjae Jeon writes:
This became much better than before. However, we have to consolidate the
code with fat_search_long() finally.
E.g. this version is having the issue already fixed. If there is
corruption in fat cluster-chain, it lead to infinite
loop.
Namjae Jeon linkinj...@gmail.com writes:
This became much better than before. However, we have to consolidate the
code with fat_search_long() finally.
E.g. this version is having the issue already fixed. If there is
corruption in fat cluster-chain, it lead to infinite
loop.
2012/12/5, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
This became much better than before. However, we have to consolidate
the
code with fat_search_long() finally.
E.g. this version is having the issue already fixed. If there is
corruption in fat
2012/12/4, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> 2012/12/3, OGAWA Hirofumi :
>>> Namjae Jeon writes:
>>>
From: Namjae Jeon
This patch enables rebuilding of directory inodes which are not present
in the cache.This is done by traversing the disk clusters to find the
Namjae Jeon writes:
> 2012/12/3, OGAWA Hirofumi :
>> Namjae Jeon writes:
>>
>>> From: Namjae Jeon
>>>
>>> This patch enables rebuilding of directory inodes which are not present
>>> in the cache.This is done by traversing the disk clusters to find the
>>> directory entry of the parent
Namjae Jeon linkinj...@gmail.com writes:
2012/12/3, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
From: Namjae Jeon namjae.j...@samsung.com
This patch enables rebuilding of directory inodes which are not present
in the cache.This is done by traversing
2012/12/4, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
2012/12/3, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
From: Namjae Jeon namjae.j...@samsung.com
This patch enables rebuilding of directory inodes which
2012/12/3, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> From: Namjae Jeon
>>
>> This patch enables rebuilding of directory inodes which are not present
>> in the cache.This is done by traversing the disk clusters to find the
>> directory entry of the parent directory and using its i_pos to build
Namjae Jeon writes:
> From: Namjae Jeon
>
> This patch enables rebuilding of directory inodes which are not present
> in the cache.This is done by traversing the disk clusters to find the
> directory entry of the parent directory and using its i_pos to build the
> inode.
> Do this only if the
Namjae Jeon linkinj...@gmail.com writes:
From: Namjae Jeon namjae.j...@samsung.com
This patch enables rebuilding of directory inodes which are not present
in the cache.This is done by traversing the disk clusters to find the
directory entry of the parent directory and using its i_pos to
2012/12/3, OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
From: Namjae Jeon namjae.j...@samsung.com
This patch enables rebuilding of directory inodes which are not present
in the cache.This is done by traversing the disk clusters to find the
directory
42 matches
Mail list logo
