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
Attachment:
signature.asc
Description: PGP signature
