> 1. ranges of ext2 blocks for freeing. Action: mark them free in the
> bitmap.
> 2. ext2 indirect blocks for freeing. Action: read the block, go through
> its contents and feed the appropriate requests into the queue 1 (including
> the block itself).
> 3. Ditto for double indirect blocks. Queues being fed: 2 and 1.
> 4. Triple indirect. Ditto, target queues 3 and 1.
> 5. Ext2 inodes for freeing. Action: feed appropriate requests to #1--4 and
Guys, this is all convoluted ways of fighting symptoms. The cause of
"rm taking a long time" is that the indirect blocks are scattered all
over the disk.
Now that can be fixed in two ways.
One is to allocate the indirect blocks in a way that they are
clustered together a bit more. On a 1k filesystem, we can speed up
"rm" a factor of 10 by allocating 10 indirect blocks near eachother.
That means that the delay of removing a 1G file is still measureable,
but on the order of 3 to 6 seconds, which is acceptable for handling
LARGE files.
Another would be to make ext2fs use "extents". I believe I've heard
that work is already on its way to do this.
If we have extents, then a single "indirect" block will most likely
give us 10 to 100 times more data-blocks that need freeing. Clearing
the bitmaps might become the bottleneck in that case.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/