[lkml]   [1999]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...
Alexander Viro wrote:
> > rm bigfile

> 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.


** ** ** +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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site