On Wed, 29 Jun 2016 14:19:23 -0400, "Austin S. Hemmelgarn" <ahferro...@gmail.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 ? > > > 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. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
