[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...
Alexander Viro wrote:
> On Tue, 18 May 1999, Rogier Wolff wrote:
> > 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.
> Nope. It is $DEITY-awful amount of waiting/retries/schedule() calls in
> ext2_truncate(). Look and you'll see. That, and zeroing indirect blocks
> (unnecessary for this usage of ext2_truncate()).

Ok, So we could speed things up a bit by not writing back the indirect
blocks. Under minix-fs, datablocks that got freed before getting
written to disk (e.g. a tempfile from the compiler), would never get
written. I've been told that ext2fs does the same. Doesn't the same
hold for the indirectblocks? They should get freed after getting
zeroed, and then never getten written to disk.

The "improve performance by a factor of 16" which i predicted for a 4k
blocksize filesystem was a factor fo 30 according to someones (pretty
inaccurate) measurements.

Allocating say 10 indirect blocks together would improve
rm-performance by a factor of 10. That is what I consider significant.


** ** ** +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.033 / U:6.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site