Re: [PATCH v6 25/28] btrfs: relocate block group to repair IO failure in HMZONED

Josef Bacik
2019-12-17T22:04:11Z

On 12/12/19 11:09 PM, Naohiro Aota wrote:
> When btrfs find a checksum error and if the file system has a mirror of the
> damaged data, btrfs read the correct data from the mirror and write the
> data to damaged blocks. This repairing, however, is against the sequential
> write required rule.
>
> We can consider three methods to repair an IO failure in HMZONED mode:
> (1) Reset and rewrite the damaged zone
> (2) Allocate new device extent and replace the damaged device extent to the
> new extent
> (3) Relocate the corresponding block group
>
> Method (1) is most similar to a behavior done with regular devices.
> However, it also wipes non-damaged data in the same device extent, and so
> it unnecessary degrades non-damaged data.
>
> Method (2) is much like device replacing but done in the same device. It is
> safe because it keeps the device extent until the replacing finish.
> However, extending device replacing is non-trivial. It assumes
> "src_dev>physical == dst_dev->physical". Also, the extent mapping replacing
> function should be extended to support replacing device extent position in
> one device.
>
> Method (3) invokes relocation of the damaged block group, so it is
> straightforward to implement. It relocates all the mirrored device extents,
> so it is, potentially, a more costly operation than method (1) or (2). But
> it relocates only using extents which reduce the total IO size.
>
> Let's apply method (3) for now. In the future, we can extend device-replace
> and apply method (2).
>
> For protecting a block group gets relocated multiple time with multiple IO
> errors, this commit introduces "relocating_repair" bit to show it's now
> relocating to repair IO failures. Also it uses a new kthread
> "btrfs-relocating-repair", not to block IO path with relocating process.
>
> This commit also supports repairing in the scrub process.
>
> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef