Re: [Ext2-devel] [RFC] [PATCH] Reducing average ext2 fsck time through fs-wide dirty bit]

[Andreas Dilger]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/