Christoph Anton Mitterer posted on Tue, 06 Mar 2018 01:57:58 +0100 as excerpted:
> In the meantime I had a look of the remaining files that I got from the > btrfs-restore (haven't run it again so far, from the OLD notebook, so > only the results from the NEW notebook here:): > > The remaining ones were multi-GB qcow2 images for some qemu VMs. > I think I had non of these files open (i.e. VMs running) while in the > final corruption phase... but at least I'm sure that not *all* of them > were running. > > However, all the qcow2 files from the restore are more or less garbage. > During the btrfs-restore it already complained on them, that it would > loop too often on them and whether I want to continue or not (I choose n > and on another full run I choose y). > > Some still contain a partition table, some partitions even filesystems > (btrfs again)... but I cannot mount them. Just a note on format choices FWIW, nothing at all to do with your current problem... As my own use-case doesn't involve VMs I'm /far/ from an expert here, but if I'm screwing things up I'm sure someone will correct me and I'll learn something too, but it does /sound/ reasonable, so assuming I'm remembering correctly from a discussion here... Tip: Btrfs and qcow2 are both copy-on-write/COW (it's in the qcow2 name, after all), and doing multiple layers of COW is both inefficient and a good candidate to test for corner-case bugs that wouldn't show up in more normal use-cases. Assuming bug-free it /should/ work properly, of course, but equally of course, bug-free isn't an entirely realistic assumption. =8^0 ... And you're putting btrfs on qcow2 on btrfs... THREE layers of COW! The recommendation was thus to pick what layer you wish to COW at, and use something that's not COW-based at the other layers. Apparently, qemu has raw-format as a choice as well as qcow2, and that was recommended as preferred for use with btrfs (and IIRC what the recommender was using himself). But of course that still leaves cow-based btrfs on both the top and the bottom layers. I suppose which of those is best to remain btrfs, while making the other say ext4 as widest used and hopefully safest general purpose non-COW alternative, depends on the use-case. Of course keeping btrfs at both levels but nocowing the image files on the host btrfs is a possibility as well, but nocow on btrfs has enough limits and caveats that I consider it a second-class "really should have used a different filesystem for this but didn't want to bother setting up a dedicated one" choice, and as such, don't consider it a viable option here. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
