2017-09-12 14:12 GMT+03:00 Adam Borowski <kilob...@angband.pl>: > On Tue, Sep 12, 2017 at 02:01:53PM +0300, Timofey Titovets wrote: >> > On 12/09/17 13:32, Adam Borowski wrote: >> >> Just use raw -- btrfs already has every feature that qcow2 has, and >> >> does it better. This doesn't mean btrfs is the best choice for hosting >> >> VM files, just that raw-over-btrfs is strictly better than >> >> qcow2-over-btrfs. >> > >> > Thanks for advice, I wasn't sure I won't lose features, and was too lazy to >> > investigate/ask. Now it looks simple. >> >> The main problem with Raw over Btrfs is that (IIRC) no one support >> btrfs features. >> >> - Patches for libvirt not merged and obsolete >> - Patches for Proxmox also not merged >> - Other VM hypervisor like Virtualbox, VMware just ignore btrfs features. >> >> So with raw you will have a problems like: no snapshot support > > Why would you need support in the hypervisor if cp --reflink=always is > enough? Likewise, I wouldn't expect hypervisors to implement support for > every dedup tool -- it'd be a layering violation[1]. It's not emacs or > systemd, you really can use an external tool instead of adding a lawnmower > to the kitchen sink. > > > Meow! > > [1] Yeah, talking about layering violations in btrfs context is a bit weird, > but it's better to at least try.
In that case why Hypervisors add support for LVM snapshots, ZFS, RBD Snapshot & etc? User can do that by hand, so it's useless, nope? (rhetorical question) This is not about layering violation with about teaming and integration between tools. -- Have a nice day, Timofey. -- 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
