[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ext4
Subject:    Re: [Ext2-devel] [lkml FW]: ext3 reservation strangeness?!
From:       Mingming Cao <cmm () us ! ibm ! com>
Date:       2004-10-26 19:03:23
Message-ID: 1098817413.9552.7534.camel () w-ming2 ! beaverton ! ibm ! com
[Download RAW message or body]

On Tue, 2004-10-26 at 02:59, Karl Vogel wrote:
> Originally posted to LKML.. but this ML is better suited I guess.
> 
> -----Original Message-----
> When copying a file on 2.6.9-mm1 with the ext3 reservation code,
> I noticed that there were a lot of fragments. Doing the same when
> the filesystem is mounted with 'noreservation' seems to produce
> better results?! Or am I interpreting this incorrectly?
>

At first I thought this should not happen, but think again, I think it
is possible, two possible reasons:

1) ext3_find_goal() randomly(based on the pid) select a goal block for
the very first block to allocate. It is possible that ext3_find_goal
generate a bad start for the reservation case-- the bitmap around the
goal block has a lot of other files already allocated. But for the
non-reservation case, it picked up a good place to place the file, there
is no(or only a few) other files nearby. I don't know if we could do
something here.

2)But even if above is true, the root cause I think is there is some
optimization in the non-reservation case that is missing in the
reservation case. Currently, whenever we find a window open for
reservation, we will search the block bitmap to find if there is free
bit inside the window to reserve; if there is, then we make a
reservation start from the first free bit. However, it is possible that
the reserved window only contains 1 or 2 or a little free blocks, so we
got fragment here.

For the non-reservation case, if the goal block is not avaliable ,it
will search the first free byte in the block bitmap, and allocate block
from there if there is a free byte. 

for example, if your block group bitmap is like this before you do the
cp:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ...
x x x 0 x 0 x 0 x 0  x  0  x  0  x  0  0   0  0  0  0  0  0  0  0  0

'x' is used, '0' is unused and we need 4 blocks for the file to copy,
and the ext3_find_goal() returns goal block as block 2,(it is used
already)

In the reservation case, since block 2 is not avalible, it will make
reservation from block 4-11, and the blocks allocated for file is
4.6.8.10, we have 4 fragments here.

In the non reservation case, since block 2 is not avalible, it will find
the first free byte from the bitmap, and allocated blocks for there. The
blocks allocated 16-13, we have only 1 extent.

We probably should make reservation only if we find a free byte, (not
just a free bit), or the window has 1/2 window size free blocks. But 
what if we could not find such a place to make reservation within the
block group? Shall we leave those holes unfilled and move onto the next
block group? Or shall we try to allocate blocks within the group without
reservation?

Mingming



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Ext2-devel mailing list
Ext2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ext2-devel
[prev in list] [next in list] [prev in thread] [next in thread]