Re: Is the default discard mode to ignore?
On Thu, Aug 06, 2020 at 01:35:45PM -0600, Chris Murphy wrote:
virt-manager 'Discard Mode" defaults to "Hypervisor
default" but I'm
not sure if there's ever a case where this could translate into
on/unmap?
What problems could result if the guest OS file system mount option
were to default to 'discard'? Is it reasonable to expect discards will
be inhibited by default because of Discard Mode's default setting?
What I'm concerned about is the use case of either raw or qcow2
backing files that have been fully preallocated. If discards pass
through to the backing file, they become sparse files, which may be
suboptimal due to ensuing fragmentation. Of course it's a trade off,
you also gain efficient storage of the backing file - it consumes only
what the guest uses. But I think the more compatible behavior is to
not do discards out of the box. Someone who wants sparse backing
files, I expect, will (a) create sparse backing files and (b) set
discard mode to unmap.
And similarly, who wants fully allocated files will fully allocate them and set
the mode to `ignore`.
What we mean by "hypervisor default" is that we let the underlying hypervisor
(in this case only QEMU) decide. The reason for that is that we could not pass
any option to the hypervisor before we introduced this option in libvirt and XML
definitions from that time must keep working the same way they did before due to
our back-compatibility promise. Sometimes we can fill in the default from how it
worked before, but most of the time it is more work, mostly because you need to
prove that the option you selected was always the case etc.
HTH,
Martin
Background and genesis of all of this:
RFE: kickstart option to control discard configuration
https://bugzilla.redhat.com/show_bug.cgi?id=1860720
Thanks,
--
Chris Murphy
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)