Tristan Ye
2010-Mar-25 08:35 UTC
[Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
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 at 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
Tao Ma
2010-Mar-25 23:36 UTC
[Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
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 at 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); >
tristan
2010-Mar-26 01:25 UTC
[Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
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 at 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); >> >
Tao Ma
2010-Mar-26 01:26 UTC
[Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
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 at 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); >>> >> >
tristan
2010-Mar-26 01:32 UTC
[Ocfs2-devel] [PATCH 1/1] Ocfs2: __ocfs2_find_path() needs to treat hole correctly.
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 at 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); >>>> >>> >>