> I find Laszlo's case with a preallocated image particularly surprising
> because the behaviour isn't supposed to have changed at all for
> preallocated images, at least if the heuristics still detects them as
> such.
But isn't that "if" at the core of this problem? What happens if the
detection misfires? (This is not a loaded question, I'm not implying any
particular circumstances; I'm just surprised that heuristics could be
considered at all.)
> Once a preallocated image becomes almost fully allocated, it's
> expected that we won't detect it any more. So, Laszlo, do you know how
> much of your images was allocated? 'qemu-img check' prints the
> allocation statistics.
I don't have the images any longer, and since then, I've been running
qemu 4.0 (for my upstream QEMU binaries).
However, I can say some things (with both affected VMs being Fedora
installations):
- As noted earlier, the images were formatted for 100GB, with
preallocation=metadata.
- I always install Fedora from Live ISOs (never starting with
pre-installed images), and right after installation, "du" on the host
side always reports 5-8 GB usage. Definitely never more than 10GB. So
I'd say these images were very sparsely populated.
- I always use qcow2 images like this, in the domain XMLs:
and I always use virtio-scsi so that discard='unmap' actually have an
effect.
- I occasionally run "fstrim" in the guest, and / or "virsh domfstrim"
on the host. (And re-run "du" on the host side in every such case.)
- Right after installation (with the VM powered down), I might compress
the image with "qemu-img convert -c"; but I don't believe I've done
that too recently.
- The general idea on my end is that I'd like to limit guest disk usage
by the *host* disk's free space, and not by an arbitrary pre-set disk
image size. Hence 100GB stands for "infinity" (I might have used 1TB
just as well), and error_policy='enospace' lets me act, should a guest
actually run out of space, on the host disk. Finally, discard='unmap'
prevents waste. I use "preallocation=metadata" because the initial
size cost is negligible, but I perceive writes to be faster.
Hopefully this helps at least a tiny bit... Thanks!
In reply to Kevin's comment#13:
> I find Laszlo's case with a preallocated image particularly surprising
> because the behaviour isn't supposed to have changed at all for
> preallocated images, at least if the heuristics still detects them as
> such.
But isn't that "if" at the core of this problem? What happens if the
detection misfires? (This is not a loaded question, I'm not implying any
particular circumstances; I'm just surprised that heuristics could be
considered at all.)
> Once a preallocated image becomes almost fully allocated, it's
> expected that we won't detect it any more. So, Laszlo, do you know how
> much of your images was allocated? 'qemu-img check' prints the
> allocation statistics.
I don't have the images any longer, and since then, I've been running
qemu 4.0 (for my upstream QEMU binaries).
However, I can say some things (with both affected VMs being Fedora
installations):
- As noted earlier, the images were formatted for 100GB, with =metadata.
preallocation
- I always install Fedora from Live ISOs (never starting with
pre-installed images), and right after installation, "du" on the host
side always reports 5-8 GB usage. Definitely never more than 10GB. So
I'd say these images were very sparsely populated.
- I always use qcow2 images like this, in the domain XMLs:
<driver name='qemu' type='qcow2' cache='writeback' policy= 'enospace' discard='unmap'/>
error_
and I always use virtio-scsi so that discard='unmap' actually have an
effect.
- I occasionally run "fstrim" in the guest, and / or "virsh domfstrim"
on the host. (And re-run "du" on the host side in every such case.)
- Right after installation (with the VM powered down), I might compress
the image with "qemu-img convert -c"; but I don't believe I've done
that too recently.
- The general idea on my end is that I'd like to limit guest disk usage 'enospace' lets me act, should a guest metadata" because the initial
by the *host* disk's free space, and not by an arbitrary pre-set disk
image size. Hence 100GB stands for "infinity" (I might have used 1TB
just as well), and error_policy=
actually run out of space, on the host disk. Finally, discard='unmap'
prevents waste. I use "preallocation=
size cost is negligible, but I perceive writes to be faster.
Hopefully this helps at least a tiny bit... Thanks!