[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...

On Wed, 19 May 1999, Rogier Wolff wrote:

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

Sorry, no. Doesn't work that way.

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

IOW complexity of current implementation is pretty bad. And that can be
fixed. Putting indirect blocks together may improve performance on
truncate() (after all, disks usually read the whole track and have cache),
but will hamper sequential reads.

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