Regarding QEMU guest HDD images on btrfs:
Both BTRFS and ZFS are COW-based filesystems and I've come across some warning notes in the interwebs, that this COW mechanism results in unpleasant and worsening fragmentation problem, if such FS is used as underlying storage for files that get "overwritten in place" a lot - such as guest VM hdd images or database extents. Fragmentation hurts even on SSD's, because it multiplies the number of IOps required to read the file. It is especially detrimental on spinning rust with its slow heads (some 60-100 random IOps). ZFS is namely good for storing backups = files that you store once, but after that you leave them alone (there are no in-place rewrites). For backups, the dedupe features of ZFS come in handy. In btrfs, the COW can be suppressed, using the "nodatacow" mount option (on a whole BTRFS volume), or you can apply it on individual subvolumes using the chattr +C command. This will rid you of COW and fragmentation for normal operation. But, if you try some snapshots, COW will still activate, because there's no way around it for snapshots. On a tangential note, the DeviceMapper subsystem in Linux, which is the basis of Linux LVM, has a "snapshot-origin" option (an option to dmsetup). Yes, DeviceMapper and LVM can do snapshots too, at the block layer. By default, COW allocates new blocks for a write, and splices them to the live "origin" file, whereas the snapshot file receives the stale blocks just deallocated from the origin file... So the "snapshot-origin" option turns this around, data are replaced in- place in the origin file upon mod, and the snapshot file gets a few extra blocks allocated, and the old data from the origin file gets copied onto this new storage... Have you checked Proxmox? It has a nice GUI, and uses the LVM for storage (gives LV's to guests). To save disk space on the hypervisor instance, you should aim to use sparse image files or thin-provisione LVM. And, couple these to DISCARD emulation in the guest (in the virtio storage device). Frank
