Messages in this thread | | | Subject | Re: Deletion of big files... | Date | Tue, 18 May 1999 09:55:09 +0200 (MEST) | From | (Rogier Wolff) |
| |
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.
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/
| |