On Mon, Jan 25, 2016 at 12:30 AM, Matthias G. Eckermann <mge@suse.com> wrote:
Hello all,
On 2016-01-24 T 16:25 -0700 Chris Murphy wrote:
But what does still happen is VM images cause data chunks to be allocated faster than metadata chunks as the VM image grows. So it's possible to fill up a volume with a high data to metadata chunk ratio that isn't released even if most of the VM's are deleted. You'd have a lot of nearly empty data chunks but can still have totally full metadata chunks and end up with ENOSPC.
That's correct in theory, however as a "proactive remedy", subvolumes such as /var/lib/libvirt should be marked as "NoCOW", to reduce fragmentation and metadata overhead. If this is not the case in Tumbleweed yet, I suggest to open a bugreport (you can check with "lsattr -a /var/lib/libvirt").
The Tumbleweed installation/partitioning overview shows nocow for a several subvolumes including /var/lib/libvirt/images. This is mainly for performance reasons though as in short order raw or qcow2 files will have tens of thousands of fragments. This is much less of a problem on SSD than a HDD. The fragmentation also depends on the guest file system, there are reports on the Btrfs list that NTFS is particularly brutal, and also the libvirt/qemu caching method. I've been using Btrfs in the guest, qcow2 file on Btrfs on the host with unsafe caching for quite some time with good performance, not super hideous fragmentation, and no corruption even when the VM crashes or is force quit. But it's not a configuration recommended for production. Honestly I think it's better to point guest Btrfs to an VG/LV. A drawback to nocow is it also implies nodatasum and disables compression. So it's a tradeoff. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org