* [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
@ 2010-03-25 8:35 Tristan Ye
2010-03-25 23:36 ` Tao Ma
0 siblings, 1 reply; 5+ messages in thread
From: Tristan Ye @ 2010-03-25 8:35 UTC (permalink / raw)
To: ocfs2-devel
Currently, __ocfs2_find_path() was lack of a mechanism to detect
a hole between two extent blocks if the cpos we want to search is
within the hole, as a result, the last rec will be returned incorrectly.
This patch attempts to detect a hole, and return the rightmost
extent block preceding the hole.
Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
---
fs/ocfs2/alloc.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 9f8bd91..2638a18 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -1841,6 +1841,17 @@ static int __ocfs2_find_path(struct ocfs2_caching_info *ci,
ocfs2_rec_clusters(el, rec);
if (cpos >= le32_to_cpu(rec->e_cpos) && cpos < range)
break;
+
+ /*
+ * Return the rightmost extent block leftly adjacent
+ * to a hole if there is any between two extent blocks.
+ *
+ * Otherwise, we get the last rec of this block unexpectly.
+ */
+ if (cpos < le32_to_cpu(rec->e_cpos)) {
+ i--;
+ break;
+ }
}
blkno = le64_to_cpu(el->l_recs[i].e_blkno);
--
1.5.5
^ permalink raw reply related [flat|nested] 5+ messages in thread* [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
2010-03-25 8:35 [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly Tristan Ye
@ 2010-03-25 23:36 ` Tao Ma
2010-03-26 1:25 ` tristan
0 siblings, 1 reply; 5+ messages in thread
From: Tao Ma @ 2010-03-25 23:36 UTC (permalink / raw)
To: ocfs2-devel
Tristan Ye wrote:
> Currently, __ocfs2_find_path() was lack of a mechanism to detect
> a hole between two extent blocks if the cpos we want to search is
> within the hole, as a result, the last rec will be returned incorrectly.
>
Do you mean extent block or extent rec? The extent block are contiguous
and there should be no hole.
oh, here. We should never meet with this. So Nack.
Regards,
Tao
>
> This patch attempts to detect a hole, and return the rightmost
> extent block preceding the hole.
>
> Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
> ---
> fs/ocfs2/alloc.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
> index 9f8bd91..2638a18 100644
> --- a/fs/ocfs2/alloc.c
> +++ b/fs/ocfs2/alloc.c
> @@ -1841,6 +1841,17 @@ static int __ocfs2_find_path(struct ocfs2_caching_info *ci,
> ocfs2_rec_clusters(el, rec);
> if (cpos >= le32_to_cpu(rec->e_cpos) && cpos < range)
> break;
> +
> + /*
> + * Return the rightmost extent block leftly adjacent
> + * to a hole if there is any between two extent blocks.
> + *
> + * Otherwise, we get the last rec of this block unexpectly.
> + */
> + if (cpos < le32_to_cpu(rec->e_cpos)) {
> + i--;
> + break;
> + }
> }
>
> blkno = le64_to_cpu(el->l_recs[i].e_blkno);
>
^ permalink raw reply [flat|nested] 5+ messages in thread* [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
2010-03-25 23:36 ` Tao Ma
@ 2010-03-26 1:25 ` tristan
2010-03-26 1:26 ` Tao Ma
0 siblings, 1 reply; 5+ messages in thread
From: tristan @ 2010-03-26 1:25 UTC (permalink / raw)
To: ocfs2-devel
Tao Ma wrote:
> Tristan Ye wrote:
>> Currently, __ocfs2_find_path() was lack of a mechanism to detect
>> a hole between two extent blocks if the cpos we want to search is
>> within the hole, as a result, the last rec will be returned incorrectly.
>>
> Do you mean extent block or extent rec? The extent block are
> contiguous and there should be no hole.
> oh, here. We should never meet with this. So Nack.
I meant the extent records in none-leaf extent blocks, may the hole
exist between these recs?
Tristan.
>
> Regards,
> Tao
>> This patch attempts to detect a hole, and return the rightmost
>> extent block preceding the hole.
>>
>> Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
>> ---
>> fs/ocfs2/alloc.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
>> index 9f8bd91..2638a18 100644
>> --- a/fs/ocfs2/alloc.c
>> +++ b/fs/ocfs2/alloc.c
>> @@ -1841,6 +1841,17 @@ static int __ocfs2_find_path(struct
>> ocfs2_caching_info *ci,
>> ocfs2_rec_clusters(el, rec);
>> if (cpos >= le32_to_cpu(rec->e_cpos) && cpos < range)
>> break;
>> +
>> + /*
>> + * Return the rightmost extent block leftly adjacent
>> + * to a hole if there is any between two extent blocks.
>> + *
>> + * Otherwise, we get the last rec of this block unexpectly.
>> + */
>> + if (cpos < le32_to_cpu(rec->e_cpos)) {
>> + i--;
>> + break;
>> + }
>> }
>>
>> blkno = le64_to_cpu(el->l_recs[i].e_blkno);
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
2010-03-26 1:25 ` tristan
@ 2010-03-26 1:26 ` Tao Ma
2010-03-26 1:32 ` tristan
0 siblings, 1 reply; 5+ messages in thread
From: Tao Ma @ 2010-03-26 1:26 UTC (permalink / raw)
To: ocfs2-devel
tristan wrote:
> Tao Ma wrote:
>> Tristan Ye wrote:
>>> Currently, __ocfs2_find_path() was lack of a mechanism to detect
>>> a hole between two extent blocks if the cpos we want to search is
>>> within the hole, as a result, the last rec will be returned incorrectly.
>>>
>> Do you mean extent block or extent rec? The extent block are
>> contiguous and there should be no hole.
>> oh, here. We should never meet with this. So Nack.
>
> I meant the extent records in none-leaf extent blocks, may the hole
> exist between these recs?
no, there is no holes except the leaf extent rec.
Regards,
Tao
>
>
> Tristan.
>
>
>>
>> Regards,
>> Tao
>>> This patch attempts to detect a hole, and return the rightmost
>>> extent block preceding the hole.
>>>
>>> Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
>>> ---
>>> fs/ocfs2/alloc.c | 11 +++++++++++
>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
>>> index 9f8bd91..2638a18 100644
>>> --- a/fs/ocfs2/alloc.c
>>> +++ b/fs/ocfs2/alloc.c
>>> @@ -1841,6 +1841,17 @@ static int __ocfs2_find_path(struct
>>> ocfs2_caching_info *ci,
>>> ocfs2_rec_clusters(el, rec);
>>> if (cpos >= le32_to_cpu(rec->e_cpos) && cpos < range)
>>> break;
>>> +
>>> + /*
>>> + * Return the rightmost extent block leftly adjacent
>>> + * to a hole if there is any between two extent blocks.
>>> + *
>>> + * Otherwise, we get the last rec of this block unexpectly.
>>> + */
>>> + if (cpos < le32_to_cpu(rec->e_cpos)) {
>>> + i--;
>>> + break;
>>> + }
>>> }
>>>
>>> blkno = le64_to_cpu(el->l_recs[i].e_blkno);
>>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
2010-03-26 1:26 ` Tao Ma
@ 2010-03-26 1:32 ` tristan
0 siblings, 0 replies; 5+ messages in thread
From: tristan @ 2010-03-26 1:32 UTC (permalink / raw)
To: ocfs2-devel
Tao Ma wrote:
>
>
> tristan wrote:
>> Tao Ma wrote:
>>> Tristan Ye wrote:
>>>> Currently, __ocfs2_find_path() was lack of a mechanism to detect
>>>> a hole between two extent blocks if the cpos we want to search is
>>>> within the hole, as a result, the last rec will be returned
>>>> incorrectly.
>>>>
>>> Do you mean extent block or extent rec? The extent block are
>>> contiguous and there should be no hole.
>>> oh, here. We should never meet with this. So Nack.
>>
>> I meant the extent records in none-leaf extent blocks, may the hole
>> exist between these recs?
> no, there is no holes except the leaf extent rec.
Gotcha,
Thanks for teaching;) I thought there may be a bug along with my
punching hole patch, seems that is fine...
>
> Regards,
> Tao
>>
>>
>> Tristan.
>>
>>
>>>
>>> Regards,
>>> Tao
>>>> This patch attempts to detect a hole, and return the rightmost
>>>> extent block preceding the hole.
>>>>
>>>> Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
>>>> ---
>>>> fs/ocfs2/alloc.c | 11 +++++++++++
>>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
>>>> index 9f8bd91..2638a18 100644
>>>> --- a/fs/ocfs2/alloc.c
>>>> +++ b/fs/ocfs2/alloc.c
>>>> @@ -1841,6 +1841,17 @@ static int __ocfs2_find_path(struct
>>>> ocfs2_caching_info *ci,
>>>> ocfs2_rec_clusters(el, rec);
>>>> if (cpos >= le32_to_cpu(rec->e_cpos) && cpos < range)
>>>> break;
>>>> +
>>>> + /*
>>>> + * Return the rightmost extent block leftly adjacent
>>>> + * to a hole if there is any between two extent blocks.
>>>> + *
>>>> + * Otherwise, we get the last rec of this block
>>>> unexpectly.
>>>> + */
>>>> + if (cpos < le32_to_cpu(rec->e_cpos)) {
>>>> + i--;
>>>> + break;
>>>> + }
>>>> }
>>>>
>>>> blkno = le64_to_cpu(el->l_recs[i].e_blkno);
>>>>
>>>
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-03-26 1:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-25 8:35 [Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly Tristan Ye
2010-03-25 23:36 ` Tao Ma
2010-03-26 1:25 ` tristan
2010-03-26 1:26 ` Tao Ma
2010-03-26 1:32 ` tristan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.