> [ ... ] Instead, you can use raw files (preferably sparse unless > there's both nocow and no snapshots). Btrfs does natively everything > you'd gain from qcow2, and does it better: you can delete the master > of a cloned image, deduplicate them, deduplicate two unrelated images; > you can turn on compression, etc.
Uhmmmmm, I understand this argument in the general case (not specifically as to QCOW2 images), and it has some merit, but it is "controversial", as there are two counterarguments: * Application specifici file formats can match better application specific requirements. * Putting advanced functionality into the filesystem code makes it more complex and less robust, and Btrfs is a bit of a major example of the consequences. I put compression and deduplication as things that I reckon make a filesystem too complex. As to snapshots, I make a difference between filetree snapshots and file snapshots: the first clones a tree as of the snapshot moment, and it is a system management feature, the second provides per-file update rollback. One sort of implies the other, but using the per-file rollback *systematically*, that is a a feature an application can rely one seems a bit dangerous to me. > Once you pay the btrfs performance penalty, Uhmmmmmmmmmmm, Btrfs has a small or negative performance penalty as a general purpose filesystem, and many (more or less well conceived) tests show it performs up there with the best. The only two real costs I have to it are the huge CPU cost of doing checksumming all the time, but that's unavoidable if one wants checksumming, and that checksumming usually requires metadata duplication, that is at least 'dup' profile for metadata, and that is indeed a bit expensive. > you may as well actually use its features, The features that I think Btrfs gives that are worth using are checksumming, metadata duplication, and filetree snapshots. > which make qcow2 redundant and harmful. My impression is that in almost all cases QCOW2 is harmful, because it trades more IOPS and complexity for less disk space, and disk space is cheap and IOPS and complexity are expensive, but of course a lot of people know better :-). My preferred VM setup is a small essentially read-only non-QCOW2 image for '/' and everything else mounted via NFSv4, from the VM host itself or a NAS server, but again lots of people know better and use multi-terabyte-sized QCOW2 images :-). -- 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
