lkml.org 
[lkml]   [2006]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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