From: Mingming Cao The ext3 reservation patches changed the non-reservation block allocation path. The changes does not cause the time regression on untar.sh, but changed the disk layout. So later when run read.sh or cp.sh, it sequentially caused the regression I saw. There is a performance optimization code previously presented in mainline kernel has removed, I thought it might not appropriate for the reservation case. It turns out it hurt the non-reservation case and not optimized for the reservation case. There are another changes that are considered for reservation turned on case but not optimized for the non-reservation change. I have tested the patch against 265-mm6 on my 8way, no regression there (with reservation and with no reservation, compare with 2.6.5). --- 25-akpm/fs/ext3/balloc.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletion(-) diff -puN fs/ext3/balloc.c~ext3-reservation-regression-fix fs/ext3/balloc.c --- 25/fs/ext3/balloc.c~ext3-reservation-regression-fix 2004-04-20 23:43:10.215216408 -0700 +++ 25-akpm/fs/ext3/balloc.c 2004-04-20 23:44:25.944703776 -0700 @@ -456,7 +456,7 @@ find_next_usable_block(int start, struct r = memscan(p, 0, (maxblocks - here + 7) >> 3); next = (r - ((char *)bh->b_data)) << 3; - if (next < maxblocks && ext3_test_allocatable(next, bh)) + if (next < maxblocks && next >= start && ext3_test_allocatable(next, bh)) return next; /* @@ -538,6 +538,15 @@ repeat: goal = find_next_usable_block(start, bitmap_bh, end); if (goal < 0) goto fail_access; + if (!my_rsv) { + int i; + + for (i = 0; i < 7 && goal > start && + ext3_test_allocatable(goal - 1, + bitmap_bh); + i++, goal--) + ; + } } start = goal; _