B.H. Thanks for the reply. On Sun, Jun 28, 2015 at 7:45 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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. To recover the old device, that's what i'm trying to do. Asked on IRC also, no reply. As stated above, the device passes btrfs check without errors but cannot mount because it complains about "ongoing replace" and the replace device is missing. > Option B: In the meantime, start to check some files to see if they're > actually corrupt or if these csum errors are bogus. Tried to copy some files that are reported with bad checksums out of the "new" volume. Copy fails with messages like this: [181896.761117] BTRFS info (device md1): csum failed ino 3849795 off 1388544 csum 2566472073 expected csum 3428551483 [181896.761362] BTRFS info (device md1): csum failed ino 3849795 off 1519616 csum 2566472073 expected csum 1565909691 [181896.761997] BTRFS info (device md1): csum failed ino 3849795 extent 5084061945856 csum 2566472073 wanted 2627769260 mirror 0 [181896.769091] BTRFS info (device md1): csum failed ino 3849795 off 1257472 csum 2566472073 expected csum 4184704592 [181896.769509] BTRFS info (device md1): csum failed ino 3849795 off 1257472 csum 2566472073 expected csum 4184704592 [181897.171789] BTRFS info (device md1): csum failed ino 2940181 extent 4288477184000 csum 2566472073 wanted 1434149511 mirror 0 [181897.171984] BTRFS info (device md1): csum failed ino 2940181 extent 4288477270016 csum 2566472073 wanted 439924019 mirror 0 [181897.172199] BTRFS info (device md1): csum failed ino 2940181 extent 4288477356032 csum 2566472073 wanted 3293573949 mirror 0 > 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. Unfortunately, i don't have so much free storage, it's more than 15TB. But i do have another backup, so the recovery is not so urgent. The btrfs backup is the only place where i have the older snapshots of the data (actually, this is why we decided using btrfs on the first hand) and reformatting will mean to loose that older data. -- משיח NOW! Moshiach is coming very soon, prepare yourself! יחי אדוננו מורינו ורבינו מלך המשיח לעולם ועד! -- 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
