Re: Kernel bug during RAID1 replace

[Saint Germain <saintger@gmail.com>]

On Wed, 29 Jun 2016 11:28:24 -0600, Chris Murphy
<lists@colorremedies.com> wrote :

> > Already got a backup. I just really want to try to repair it (in
> > order to test BTRFS).
> 
> I don't know that this is a good test because I think the file system
> has already been sufficient corrupted that it can't be fixed. Part of
> the problem is that Btrfs isn't aware of faulty drives like mdadm or
> lvm yet, so it looks like it'll try to write to all devices and it's
> possible for significant confusion to happen if they're each getting
> different generation writes. Significant as in, currently beyond
> repair.
> 
> >> > On the other hand it seems interesting to repair instead of just
> >> > giving up. It gives a good look at BTRFS resiliency/reliability.
> >>
> >> On the one hand Btrfs shouldn't become inconsistent in the first
> >> place, that's the design goal. On the other hand, I'm finding from
> >> the problems reported on the list that Btrfs increasingly mounts
> >> at least read only and allows getting data off, even when the file
> >> system isn't fully functional or repairable.
> >>
> >> In your case, once there are metadata problems even with raid 1,
> >> it's difficult at best. But once you have the backup you could try
> >> some other things once it's certain the hardware isn't adding to
> >> the problems, which I'm still not yet certain of.
> >>
> >
> > I'm ready to try anything. Let's experiment.
> 
> I kinda think it's a waste of time. Someone else maybe has a better
> idea?
> 
> I think your time is better spent finding out when and why the device
> with all of these write errors happened. It must have gone missing for
> a while, and you need to find out why that happened and prevent it; OR
> you have to be really vigilent at every mount time to make sure both
> devices have the same transid (generation). In my case when I tried to
> sabotage this, being of by a generation of 1 wasn't a problem for
> Btrfs to automatically fix up but I suspect it was only a generation
> mismatch in the superblock.
> 

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 ?

Many thanks !