There is a work around for the file system not reading files when there are csum errors, which is btrfs check --init-csum-tree, but there is a caveat: You might need a newer btrfs-progs, I forget exactly what version it will reconstruct new csums, maybe 3.18 or 3.19. Older versions create a new csum tree that's empty so you get a bunch of errors for everything but you can still read files at least and see if they're corrupt or not. Before you do that, you could try btrfs restore to extract some files and see if they are really corrupt or if the csum error is bogus. If the files are corrupted, then the (new device) backup is probably useless anyway and there's no point in keeping it around. You can still keep the old device backup that won't mount in case someone eventually can say how to reset it as if the replace did not occur. I'm willing to bet that the data is OK, and you've run into some obscure bug on csum computation during the replace that went bad and it's just that the csums are all wrong. Speculation though. 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
