[lkml]   [2006]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ext2-devel] [RFC] [PATCH] Reducing average ext2 fsck time through fs-wide dirty bit]
On Mar 24, 2006  11:13 -0800, Mingming Cao wrote:
> There are reasons for zeroing indirect blocks on truncate:
> * There are limits to the size of a single journal transaction
> (1/4 of the journal size). When truncating a large fragmented
> file, it may require modifying so many block bitmaps and group
> descriptors that it forces a journal transaction to close out,
> stalling the unlink operation.
> * Because of this per-transaction limit, truncate needs to zero
> the [dt]indirect blocks starting from the end of the file, in
> case it needs to start a new transaction in the middle of the
> truncate (ext3 guarantees that a partially-completed truncate
> will be consistent/completed after a crash).
> * The read/write of the file's [dt]indirect blocks from the end of
> the file to the beginning can take a lot of time, as it does
> this in single-block chunks and the blocks are not contiguous.

See my recent post on how this performance problem could be fixed.

Cheers, Andreas
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-24 20:34    [from the cache]
©2003-2011 Jasper Spaans