Re: [PATCH 05/12] repair: update extent count after zapping duplicate blocks

Dave Chinner
2011-12-13T02:14:07Z

On Fri, Dec 02, 2011 at 12:46:24PM -0500, Christoph Hellwig wrote:
> When we find a duplicate extent in an extern format inode we do not zap
> the whole inode, but just truncate it to the point where the duplicate
> extent was found. But the current code only updates di_nblocks for the
> new size, but no di_nextents/di_anextents. In most cases this isn't noticed,
> but when moving such an inode to the lost+found directoy the consistency
> check in xfs_iformat trips over it. Fix this by updating the on-disk
> extent count as part of the inode repair.
>
> Note that we zap btree format inodes with duplicate block completely
> at this point, so this fix doesn't apply to them.
>
> Reported-by: Arkadiusz Mi??kiewicz <arekm@maven.pl>
> Tested-by: Arkadiusz Mi??kiewicz <arekm@maven.pl>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

.....

> @@ -2003,6 +2016,12 @@ process_inode_blocks_and_extents(
> xfs_ino_t lino,
> int *dirty)
> {
> + if (nblocks < nextents + anextents) {
> + do_warn(
> +_("nblocks (%" PRIu64 ") smaller than nextents for inode %" PRIu64 "\n"), nblocks, lino);
> + return 1;
> + }
> +

I thikn that should be done after validating then block/extent
counts as otherwise it doesn't handle overflows.

It also took me a moment to realise the comparison was valid
- the confusion came from the fact you are comparing different units
(block count vs extent count). It didn't occur to me immediately
that this check is valid because an extent must contain one or
more blocks, so perhaps a comment is in order.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com