Re: Kernel bug during RAID1 replace

[Chris Murphy <lists@colorremedies.com>]

On Wed, Jun 29, 2016 at 1:16 PM, Saint Germain <saintger@gmail.com> wrote:
> On Wed, 29 Jun 2016 13:08:30 -0600, Chris Murphy
> <lists@colorremedies.com> wrote :
>
>> >> > Ok I will follow your advice and start over with a fresh BTRFS
>> >> > volume. As explained on another email, rsync doesn't support
>> >> > reflink, so do you think it is worth trying with BTRFS send
>> >> > instead ? Is it safe to copy this way or rsync is more reliable
>> >> > in case of faulty BTRFS volume ?
>> >> >
>> >> If you have the space, btrfs restore would probably be the best
>> >> option. It's not likely, but using send has a risk of contaminating
>> >> the new filesystem as well.
>> >>
>> >
>> > I have to copy through the network (I am running out of disks...) so
>> > btrfs restore is unfortunately not an option.
>> > I didn't know that btrfs send could contaminate the target disk as
>> > well ?
>> > Ok rsync it is then.
>>
>> restore will let you extract files despite csum errors. I don't think
>> send will, and using cp or rsync Btrfs definitely won't hand over the
>> file.
>>
>
> That's Ok I'd prefer to avoid copying files with csum errors anyway (I
> can restore them from backups).
> However will btrfs send abort the whole operation as soon as it finds a
> csum error ?

By default yes, but it's the receive side that aborts. So you use
--max-errors 0 to let it tolerate unlimited errors, and use -v for
both send and receive to track what errors there are.

> And will I have the risk to "contaminate" the target BTRFS volume by
> using BTRFS send ?

No.

-- 
Chris Murphy