On Sat, Jun 27, 2015 at 5:17 PM, Mordechay Kaganer <mkaganer@xxxxxxxxx> wrote: > # uname -a > Linux <hostname> 3.16.0-41-generic #57~14.04.1-Ubuntu SMP Thu Jun 18 > 18:01:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > # btrfs --version > Btrfs v3.12 Well it's over a weekend so many devs may not get around to responding until Monday, if it's urgent then IRC is probably better. But the thing is, the kernel and btrfs-progs are kinda old. So I'm reasonably sure the suggestion is going to be first to upgrade both of them, it's sorta par for the course with Btrfs problems. Option A: Maybe someone has advice on how to get the demoted device to be valid again as if the replace command hadn't been used. Because then you could try the replace again with newer kernel and progs, and see if the problem still happens. That's a good question to ask on IRC if you don't have a response by tomorrow. Option B: In the meantime, start to check some files to see if they're actually corrupt or if these csum errors are bogus. Option C: Well, it's a backup so actually before A or B it's probably best to start making a new backup in case this one is beyond repair. So hopefully you have a 3rd location to put it into so you can keep both of these Btrfs volumes in their current states until you have a more clear idea what to do with them, but at least you're not delaying getting a current backup in place. Whether this new backup is Btrfs based or not is less important than actually having a backup. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
