Re: [PATCH RESEND] Btrfs: fix wrong write offset when replacing a device

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

 



On 	thu, 4 Jul 2013 16:14:23 +0200, Stefan Behrens wrote:
> Miao Xie reported the following issue:
> 
> The filesystem was corrupted after we did a device replace.
> 
> Steps to reproduce:
>  # mkfs.btrfs -f -m single -d raid10 <device0>..<device3>
>  # mount <device0> <mnt>
>  # btrfs replace start -rfB 1 <device4> <mnt>
>  # umount <mnt>
>  # btrfsck <device4>
> 
> The reason for the issue is that we changed the write offset by mistake,
> introduced by commit 625f1c8dc.
> 
> We read the data from the source device at first, and then write the
> data into the corresponding place of the new device. In order to
> implement the "-r" option, the source location is remapped using
> btrfs_map_block(). The read takes place on the mapped location, and
> the write needs to take place on the unmapped location. Currently
> the write is using the mapped location, and this commit changes it
> back by undoing the change to the write address that the aforementioned
> commit added by mistake.
> 
> Reported-by: Miao Xie <miaox@xxxxxxxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.10+
> Signed-off-by: Stefan Behrens <sbehrens@xxxxxxxxxxxxxxxx>

Thanks!

Reviewed-and-Tested-by: Miao Xie <miaox@xxxxxxxxxxxxxx>

> ---
> Resent to add stable@xxxxxxxxxxxxxxx since the regression was added
> in 3.10 RC1.
> 
>  fs/btrfs/scrub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index 4ba2a69..64a157b 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -2495,7 +2495,7 @@ again:
>  			ret = scrub_extent(sctx, extent_logical, extent_len,
>  					   extent_physical, extent_dev, flags,
>  					   generation, extent_mirror_num,
> -					   extent_physical);
> +					   extent_logical - logical + physical);
>  			if (ret)
>  				goto out;
>  
> 

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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux