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

[Matthew Wilcox]

On Fri, Mar 24, 2006 at 12:28:02PM -0700, Andreas Dilger wrote:
> Fix for this problem (inode is locked already):
> - create a modified ext3_free_branches() to do tree walking and call a
>   method instead of always calling ext3_free_data->ext3_clear_blocks
> - walk inode {d,t,}indirect blocks in forward direction, count bitmaps and
>   groups that will be modified (essentially NULL ext3_free_branches method)
> - try to start a journal handle for this many blocks + 1 (inode) +
>   1 (super) + quota + EXT3_RESERVE_TRANS_BLOCKS
>   - if journal handle is too large (journal_start() returns -ENOSPC) fall
>     back to old zero-in-steps method (vast majority of cases will be OK
>     because number of modified blocks is much fewer)

Could we try a different fallback in this case?  For example, attempt to
truncate only half as much?  Is this even allowed?

> - walk inode {d,t,}indirect blocks again deleting blocks via
>   ext3_free_blocks_sb() (updates group descriptor, bitmaps, quota), but
>   not journaling or modifying the indirect blocks
> - update i_size/i_disksize/i_blocks to new value, like ext2
> - close transaction

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