Re: [PATCH 28/39] xfs_repair: handle multiple owners of data blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> --- a/repair/dinode.c
> +++ b/repair/dinode.c
> @@ -722,6 +722,9 @@ _("Fatal error: inode %" PRIu64 " - blkmap_set_ext(): %s\n"
>  			 * checking each entry without setting the
>  			 * block bitmap
>  			 */
> +			if (type == XR_INO_DATA &&
> +			    xfs_sb_version_hasreflink(&mp->m_sb))
> +				goto skip_dup;
>  			if (search_dup_extent(agno, agbno, ebno)) {
>  				do_warn(
>  _("%s fork in ino %" PRIu64 " claims dup extent, "
> @@ -731,6 +734,7 @@ _("%s fork in ino %" PRIu64 " claims dup extent, "
>  					irec.br_blockcount);
>  				goto done;
>  			}
> +skip_dup:

For some weird reason this goto makes me sad.  I'm getting into
major nitpick terretory here, but can we avoid it?  Either duplicate
the *tot increment or find some funky condition?

Otherwise this looks fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux