On 2016-06-29 14:12, Saint Germain wrote:
On Wed, 29 Jun 2016 11:28:24 -0600, Chris Murphy
<li...@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 ?

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.

--
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

Reply via email to