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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
