Christoph Anton Mitterer posted on Tue, 06 Mar 2018 01:57:58 +0100 as
> 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
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
... 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
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
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