On Sun, Jun 28, 2015 at 12:50 PM, Noah Massey <noah.massey@xxxxxxxxx> wrote: > On Sun, Jun 28, 2015 at 2:02 PM, Mordechay Kaganer <mkaganer@xxxxxxxxx> wrote: >> 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. > > Standard disclaimer, not a dev, just a user. > The following worked for me to recover the old device after > reproducing your situation: > (where loop0 is my "old" device) > > # mount -t btrfs -o degraded /dev/loop0 /mnt > # btrfs replace cancel /mnt > # btrfs umount /mnt > # mount -t btrfs /dev/loop0 /mnt > > mount now succeeds without error. Neat trick! > > $ uname -r > 4.1.0 > $ btrfs version > btrfs-progs v4.1 Yeah I definitely advise a newer kernel and progs. Even if this trick works with the older kernel (seems reasonably likely) that the next attempt at btrfs replace needs to happen with a newer kernel and progs anyway. Bit off topic question is the device used as the target for replacement has superblocks from the first (failed, bad csum) attempt. So I wonder to what degree it's non-deterministic to try this again without erasing at least the old superblocks first? They have the same UUID is the thing; if the UUID from a different volume were used, there's no ambiguity between the stale and new data, but is there any possibility of confusion with a new attempt when UUID is the same? -- 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
