[PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal
grp_goal 0 is a genuine goal (unlike -1),
so ext2_try_to_allocate_with_rsv should treat it as such.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 +
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.0 +
@@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
-* 0 grp_goal EXT2_BLOCKS_PER_GROUP(sb)
+* 0 = grp_goal EXT2_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(my_rsv-rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal 0) {
+ } else if (grp_goal = 0) {
int curr = my_rsv-rsv_end -
(grp_goal + group_first_block) + 1;
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
On Tue, 2006-11-28 at 17:40 +, Hugh Dickins wrote: After several days of testing ext2 with reservations, it got caught inside ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the free block guaranteed to be included (unless there's contention). Hmm, I suspect there is other issue: alloc_new_reservation should not repeatedly allocating the same window, if ext2_try_to_allocate repeatedly fails to find a free block in that window. find_next_reservable_window() takes my_rsv (the old window that he thinks there is no free block) as a guide to find a window after the end block of my_rsv, so how could this happen? Fix the range to find_next_usable_block's memscan: the scan from here (0xcfe) up to (but excluding) maxblocks (0xd0e) needs to scan 3 bytes not 2 (the relevant bytes of bitmap in this case being f7 df ff - none 00, but the premature cutoff implying that the last was found 00). alloc_new_reservation() reserved a window with free block, when come to the time to claim it, it scans the window again. So it seems that the range of the the scan is too small: p = ((char *)bh-b_data) + (here 3); r = memscan(p, 0, (maxblocks - here + 7) 3); next = (r - ((char *)bh-b_data)) 3; - next is -1 if (next maxblocks next = here) return next; -- falls to false branch here = bitmap_search_next_usable_block(here, bh, maxblocks); return here; So we failed to find a free byte in the range. That's seems fine to me. It's only a nice thing to have -- try to allocate a block in a place where it's neighbors are all free also. If it fails, it will search the window bit by bit. So I don't understand why it is not being recovered by bitmap_search_next_usable_block(), which test the bitmap bit by bit? Is this a problem for mainline ext2? No, because the size in its memscan is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of 8. Is this a problem for ext3 or ext4? No, because they have an additional extN_test_allocatable test which rescues them from the error. Hmm, if the error is it prematurely think there is no free block in the range (bitmap on disk), then even in ext3/4, it will not bother checking the jbd copy of the bitmap. I am not sure this is the cause that ext3/4 may not has the problem. But the bigger question is, why does the my_rsv case come here to find_next_usable_block at all? Because grp_goal is -1? Doesn't its 64-bit boundary limit, and its memscan, blithely ignore what the reservation prepared? I agree with you that the double check is urgly. But it's necessary:( If there to prevent contention: other file make steal that free block we reserved for this file, in the case filesystem is full of reservation... It's messy too, the complement of the memscan being that i 7 loop over in ext2_try_to_allocate. I think this ought to be cleaned up, in ext2+reservations and ext3 and ext4. The i7 loop there is for non reservation case. Since find_next_usable_block() could find a free byte, it's trying to avoid filesystem holes by shifting the start of the free block for at most 7 times. Thanks! Mingming fs/ext2/balloc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 + +++ linux/fs/ext2/balloc.c2006-11-27 19:28:41.0 + @@ -570,7 +570,7 @@ find_next_usable_block(int start, struct here = 0; p = ((char *)bh-b_data) + (here 3); - r = memscan(p, 0, (maxblocks - here + 7) 3); + r = memscan(p, 0, ((maxblocks + 7) 3) - (here 3)); next = (r - ((char *)bh-b_data)) 3; if (next maxblocks next = here) - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end
On Tue, 2006-11-28 at 17:41 +, Hugh Dickins wrote: rsv_end is the last block within the reservation, so alloc_new_reservation should accept start_block == rsv_end as success. Signed-off-by: Hugh Dickins [EMAIL PROTECTED] --- Thanks, Acked. This is not a problem for now, as the default window size is 8 blocks, and we never shrink the window size. But it could be a issue in the future, if the reservation window could be dynamically shrink, when it keep failing to create a new(large) reservation window, or we keep throw away a just-allocated-window as the application is doing very seeky random write. fs/ext2/balloc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 + +++ linux/fs/ext2/balloc.c2006-11-27 19:28:41.0 + @@ -950,7 +950,7 @@ retry: * check if the first free block is within the * free space we just reserved */ - if (start_block = my_rsv-rsv_start start_block my_rsv-rsv_end) + if (start_block = my_rsv-rsv_start start_block = my_rsv-rsv_end) return 0; /* success */ /* * if the first free bit we found is out of the reservable space - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
On Tue, 28 Nov 2006, Mingming Cao wrote: On Tue, 2006-11-28 at 17:40 +, Hugh Dickins wrote: After several days of testing ext2 with reservations, it got caught inside ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the free block guaranteed to be included (unless there's contention). Hmm, I suspect there is other issue: alloc_new_reservation should not repeatedly allocating the same window, if ext2_try_to_allocate repeatedly fails to find a free block in that window. find_next_reservable_window() takes my_rsv (the old window that he thinks there is no free block) as a guide to find a window after the end block of my_rsv, so how could this happen? Hmmm. I haven't studied that part of the code, but what you say sounds sensible: that would leave more to be explained, yes. I guess it would happen if all the rest of the bitmap were either allocated or reserved, but I don't believe that was the case here: I have noted that the map was all 00s from offset 0x1ae onwards, plenty unallocated; I've not recorded the following reservations, but it seems unlikely they covered the remaining free area (and still covered it even when the remaining tasks got to the point of just waiting for this one). Fix the range to find_next_usable_block's memscan: the scan from here (0xcfe) up to (but excluding) maxblocks (0xd0e) needs to scan 3 bytes not 2 (the relevant bytes of bitmap in this case being f7 df ff - none 00, but the premature cutoff implying that the last was found 00). alloc_new_reservation() reserved a window with free block, when come to the time to claim it, it scans the window again. So it seems that the range of the the scan is too small: The range of the scan is 1 byte too small in this case, yes. p = ((char *)bh-b_data) + (here 3); r = memscan(p, 0, (maxblocks - here + 7) 3); next = (r - ((char *)bh-b_data)) 3; - next is -1 I don't understand you: next was not -1, it was 0xd08. if (next maxblocks next = here) return next; -- falls to false branch No, it passed the next maxblocks next = here test (maxblocks being 0xd0e and here being 0xcfe), so returned pointing to an allocated block - then the caller finds it cannot set the bit. here = bitmap_search_next_usable_block(here, bh, maxblocks); return here; So we failed to find a free byte in the range. That's seems fine to me. It's only a nice thing to have -- try to allocate a block in a place where it's neighbors are all free also. If it fails, it will search the window bit by bit. So I don't understand why it is not being recovered by bitmap_search_next_usable_block(), which test the bitmap bit by bit? It already returned, it doesn't reach that line. Is this a problem for mainline ext2? No, because the size in its memscan is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of 8. Is this a problem for ext3 or ext4? No, because they have an additional extN_test_allocatable test which rescues them from the error. Hmm, if the error is it prematurely think there is no free block in the range (bitmap on disk), then even in ext3/4, it will not bother checking the jbd copy of the bitmap. I am not sure this is the cause that ext3/4 may not has the problem. In the ext3/4 case, it indeed won't bother to check the jbd copy (having found this bitmap bit set), it'll fall through to the bitmap_search_next_usable_block you indicated above, and that should do the right thing, finding the first free bit in the area originally reserved. But the bigger question is, why does the my_rsv case come here to find_next_usable_block at all? Because grp_goal is -1? Well, yes, but my point is that we've got a reservation, and we're hoping to allocate from it (even though we've given up on the goal), but find_next_usable_block is not respecting it at all - liable to be allocating out of others' reservations instead. Doesn't its 64-bit boundary limit, and its memscan, blithely ignore what the reservation prepared? I agree with you that the double check is urgly. But it's necessary:( If there to prevent contention: other file make steal that free block we reserved for this file, in the case filesystem is full of reservation... I agree it's necessary to recheck the allocation; I disagree that the 64-bit boundary limit and memscan are appropriate when my_rsv is set. It's messy too, the complement of the memscan being that i 7 loop over in ext2_try_to_allocate. I think this ought to be cleaned up, in ext2+reservations and ext3 and ext4. The i7 loop there is for non reservation case. Since find_next_usable_block() could find a free byte, it's trying to avoid filesystem holes by shifting
Re: Boot failure with ext2 and initrds
On Tue, 28 Nov 2006 13:04:53 -0800 Mingming Cao [EMAIL PROTECTED] wrote: Thanks, I have acked most of them, and will port them to ext3/4 soon. You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is unclear? - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal
On Tue, 2006-11-28 at 17:42 +, Hugh Dickins wrote:
grp_goal 0 is a genuine goal (unlike -1),
so ext2_try_to_allocate_with_rsv should treat it as such.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
Acked.
Thanks,
Mingming
---
fs/ext2/balloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 +
+++ linux/fs/ext2/balloc.c2006-11-27 19:28:41.0 +
@@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 grp_goal EXT2_BLOCKS_PER_GROUP(sb)
+ * 0 = grp_goal EXT2_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(my_rsv-rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal 0) {
+ } else if (grp_goal = 0) {
int curr = my_rsv-rsv_end -
(grp_goal + group_first_block) + 1;
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ext2 balloc: use io_error label
On Tue, 2006-11-28 at 17:44 +, Hugh Dickins wrote:
ext2_new_blocks has a nice io_error label for setting -EIO,
so goto that in the one place that doesn't already use it.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Acked,
Mingming
fs/ext2/balloc.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 +
+++ linux/fs/ext2/balloc.c2006-11-27 19:28:41.0 +
@@ -1258,10 +1258,9 @@ retry_alloc:
if (group_no = ngroups)
group_no = 0;
gdp = ext2_get_group_desc(sb, group_no, gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
+
free_blocks = le16_to_cpu(gdp-bg_free_blocks_count);
/*
* skip this group if the number of
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ext2 balloc: say rb_entry not list_entry
On Tue, 2006-11-28 at 17:43 +, Hugh Dickins wrote:
The reservations tree is an rb_tree not a list, so it's less confusing to
use rb_entry() than list_entry() - though they're both just container_of().
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Acked.
Thanks,
Mingming
fs/ext2/balloc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.0 +
+++ linux/fs/ext2/balloc.c2006-11-27 19:28:41.0 +
@@ -156,7 +156,7 @@ restart:
printk(Block Allocation Reservation Windows Map (%s):\n, fn);
while (n) {
- rsv = list_entry(n, struct ext2_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext2_reserve_window_node, rsv_node);
if (verbose)
printk(reservation window 0x%p
start: %lu, end: %lu\n,
@@ -753,7 +753,7 @@ static int find_next_reservable_window(
prev = rsv;
next = rb_next(rsv-rsv_node);
- rsv = list_entry(next,struct ext2_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext2_reserve_window_node,rsv_node);
/*
* Reached the last reservation, we can just append to the
@@ -995,7 +995,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv-rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext2_reserve_window_node,
rsv_node);
+ next_rsv = rb_entry(next, struct ext2_reserve_window_node,
rsv_node);
if ((next_rsv-rsv_start - my_rsv-rsv_end - 1) = size)
my_rsv-rsv_end += size;
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Boot failure with ext2 and initrds
On Tue, 2006-11-28 at 14:33 -0800, Andrew Morton wrote: On Tue, 28 Nov 2006 13:04:53 -0800 Mingming Cao [EMAIL PROTECTED] wrote: Thanks, I have acked most of them, and will port them to ext3/4 soon. You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is unclear? sorry, just acked #4, #5 and #6. I mean to do that before I said so but they did not go out of my outbox till now ( I was out for a few hours). #1 looks correct to me now, just thought there are other issues. I will comment on that one in that thread. Mingming - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: a question about ext4_fsblk_t
On Sun, 2006-10-22 at 16:50 +0800, guomingyang wrote: I also find many places where the block number type is not changed in namei.c and dir.c. Why? They are all file logical blocks, ext4_fsblk_t is for on disk blocks. Takashi Sato has a patch to define all file logical blocks as ext3_fileblk_t, it did not make to mainline before ext4 was forked. Probably we should bring the to ext3/4 to clarify the confusions. Mingming Thank you to anyone who offer help Hello everyone: I am a student interesting in linux filesystem, I have a problem about the replace of block number type to ext4_fsblk_t. Is it complete? Or has it passed all the test? Because I have found a place like this in linux-2.6.19-rc2/fs/ext4/inode.c +struct buffer_head *ext4_bread(handle_t *handle, struct inode *inode, + int block, int create, int *err) the block's type is not changed. Although I think it will bring no mistake, I doubt about why not change it. Thank you ! guomingyang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html guomingyang - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
On Tue, 2006-11-28 at 20:07 +, Hugh Dickins wrote: On Tue, 28 Nov 2006, Mingming Cao wrote: On Tue, 2006-11-28 at 17:40 +, Hugh Dickins wrote: After several days of testing ext2 with reservations, it got caught inside ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the free block guaranteed to be included (unless there's contention). Hmm, I suspect there is other issue: alloc_new_reservation should not repeatedly allocating the same window, if ext2_try_to_allocate repeatedly fails to find a free block in that window. find_next_reservable_window() takes my_rsv (the old window that he thinks there is no free block) as a guide to find a window after the end block of my_rsv, so how could this happen? Hmmm. I haven't studied that part of the code, but what you say sounds sensible: that would leave more to be explained, yes. I guess it would happen if all the rest of the bitmap were either allocated or reserved, But bitmap_search_next_usable_block() will fail in the case the rest of bitmap were allocated, and find_next_reservable_space() will fail in the case the rest of group were all reserved. alloc_new_reservation() should not create a new window in this case. but I don't believe that was the case here: I have noted that the map was all 00s from offset 0x1ae onwards, plenty unallocated; I've not recorded the following reservations, but it seems unlikely they covered the remaining free area (and still covered it even when the remaining tasks got to the point of just waiting for this one). Fix the range to find_next_usable_block's memscan: the scan from here (0xcfe) up to (but excluding) maxblocks (0xd0e) needs to scan 3 bytes not 2 (the relevant bytes of bitmap in this case being f7 df ff - none 00, but the premature cutoff implying that the last was found 00). alloc_new_reservation() reserved a window with free block, when come to the time to claim it, it scans the window again. So it seems that the range of the the scan is too small: The range of the scan is 1 byte too small in this case, yes. p = ((char *)bh-b_data) + (here 3); r = memscan(p, 0, (maxblocks - here + 7) 3); next = (r - ((char *)bh-b_data)) 3; - next is -1 I don't understand you: next was not -1, it was 0xd08. if (next maxblocks next = here) return next; -- falls to false branch No, it passed the next maxblocks next = here test (maxblocks being 0xd0e and here being 0xcfe), so returned pointing to an allocated block - then the caller finds it cannot set the bit. Apologies for the confusion. I thought ext2_try_to_allocate() failed because we could not find a free block in the reserved window (i.e., find_next_usable_block() failed) It seems in this case, find_next_usable_block() incorrectly returns a bit it *thinks* free, but ext2_try_to_allocate() fails to claim it as it's being marked as used. So yes, Acked this fix. Thanks. here = bitmap_search_next_usable_block(here, bh, maxblocks); return here; So we failed to find a free byte in the range. That's seems fine to me. It's only a nice thing to have -- try to allocate a block in a place where it's neighbors are all free also. If it fails, it will search the window bit by bit. So I don't understand why it is not being recovered by bitmap_search_next_usable_block(), which test the bitmap bit by bit? It already returned, it doesn't reach that line. Yep. Is this a problem for mainline ext2? No, because the size in its memscan is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of 8. Is this a problem for ext3 or ext4? No, because they have an additional extN_test_allocatable test which rescues them from the error. Hmm, if the error is it prematurely think there is no free block in the range (bitmap on disk), then even in ext3/4, it will not bother checking the jbd copy of the bitmap. I am not sure this is the cause that ext3/4 may not has the problem. In the ext3/4 case, it indeed won't bother to check the jbd copy (having found this bitmap bit set), it'll fall through to the bitmap_search_next_usable_block you indicated above, and that should do the right thing, finding the first free bit in the area originally reserved. Make sense. But the bigger question is, why does the my_rsv case come here to find_next_usable_block at all? Because grp_goal is -1? Well, yes, but my point is that we've got a reservation, and we're hoping to allocate from it (even though we've given up on the goal), but find_next_usable_block is not respecting it at all - liable to be allocating out of others' reservations instead. Okay got your points.
[PATCH 1/12] ext3 balloc: reset windowsz when full
Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
patches are against ext3, and the rest are aginst ext4.
--
Subject: ext2 balloc: reset windowsz when full
From: Hugh Dickins [EMAIL PROTECTED]
ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.
--
Sync up reservation fix from ext2
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
---
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c |1 +
1 file changed, 1 insertion(+)
diff -puN fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs
2006-11-28 19:36:41.0 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:41.0
-0800
@@ -1552,6 +1552,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] ext3 balloc: fix _with_rsv freeze
-- Subject: ext2 balloc: fix _with_rsv freeze From: Hugh Dickins [EMAIL PROTECTED] After several days of testing ext2 with reservations, it got caught inside ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the free block guaranteed to be included (unless there's contention). Fix the range to find_next_usable_block's memscan: the scan from here (0xcfe) up to (but excluding) maxblocks (0xd0e) needs to scan 3 bytes not 2 (the relevant bytes of bitmap in this case being f7 df ff - none 00, but the premature cutoff implying that the last was found 00). Is this a problem for mainline ext2? No, because the size in its memscan is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of 8. Is this a problem for ext3 or ext4? No, because they have an additional extN_test_allocatable test which rescues them from the error. -- Sync up a reservation fix from ext2 in ext4 Signed-off-by: Mingming Cao [EMAIL PROTECTED] --- linux-2.6.19-rc5-cmm/fs/ext4/balloc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze fs/ext4/balloc.c --- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze 2006-11-28 19:37:12.0 -0800 +++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:12.0 -0800 @@ -747,7 +747,7 @@ find_next_usable_block(ext4_grpblk_t sta here = 0; p = ((char *)bh-b_data) + (here 3); - r = memscan(p, 0, (maxblocks - here + 7) 3); + r = memscan(p, 0, ((maxblocks + 7) 3 - (here 3)); next = (r - ((char *)bh-b_data)) 3; if (next maxblocks next = start ext4_test_allocatable(next, bh)) _ - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/12] ext3 balloc: fix off-by-one against grp_goal
--
Subject: ext2 balloc: fix off-by-one against grp_goal
From: Hugh Dickins [EMAIL PROTECTED]
grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv
should treat it as such.
--
Sync up with ext2 reservation fix in ext3
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
---
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal
fs/ext3/balloc.c
---
linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal
2006-11-28 19:36:48.0 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:48.0
-0800
@@ -1271,7 +1271,7 @@ ext3_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
-* 0 grp_goal EXT3_BLOCKS_PER_GROUP(sb)
+* 0 = grp_goal EXT3_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1307,7 +1307,7 @@ ext3_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(my_rsv-rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal 0) {
+ } else if (grp_goal = 0) {
int curr = my_rsv-rsv_end -
(grp_goal + group_first_block) + 1;
_
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
