Hello,
I find "discard":"unmap" is defaultly enabled in qemu
cmdline(libvirt
v6.6, qemu v5.1):
XML:
<disk type="file" device="disk">
<driver name="qemu" type="qcow2"/>
<source file="/var/lib/libvirt/images/new.qcow2"
index="2"/>
<backingStore/>
<target dev="sda" bus="scsi"/>
<alias name="scsi0-0-0-0"/>
<address type="drive" controller="0"
bus="0" target="0" unit="0"/>
</disk><disk type="network" device="disk">
<driver name="qemu" type="raw"
error_policy="report"/>
<source protocol="nbd" name="new"
tls="no" index="1">
<host name="localhost" port="10809"/>
</source>
<target dev="vdb" bus="virtio"/>
<alias name="virtio-disk1"/>
<address type="pci" domain="0x0000"
bus="0x02" slot="0x00"
function="0x0"/>
</disk>
QEMU cmdline:
... -blockdev
{"driver":"file","filename":"/var/lib/libvirt/images/new.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,
*"discard":"unmap"*} -blockdev
{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1
-blockdev
{"driver":"nbd","server":{"type":"inet","host":"localhost","port":"10809"},"export":"new","node-name":"libvirt-1-storage","auto-read-only":true,
*"discard":"unmap"*} -blockdev
{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}
-device
virtio-blk-pci,bus=pci.2,addr=0x0,drive=libvirt-1-format,id=virtio-disk1,werror=report,rerror=report
...
I think it's from
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_block.c#L1211
But I cannot find the reason from commit msgs or documents.
Could you please explain it?
Peter Krempa
2020-Oct-22 06:40 UTC
Re: Why "discard":"unmap" is the default option for disks
On Thu, Oct 22, 2020 at 10:57:05 +0800, Han Han wrote:> Hello, > I find "discard":"unmap" is defaultly enabled in qemu cmdline(libvirt > v6.6, qemu v5.1): > XML: > <disk type="file" device="disk"> > <driver name="qemu" type="qcow2"/> > <source file="/var/lib/libvirt/images/new.qcow2" index="2"/> > <backingStore/> > <target dev="sda" bus="scsi"/> > <alias name="scsi0-0-0-0"/> > <address type="drive" controller="0" bus="0" target="0" unit="0"/>[...]> QEMU cmdline:The -blockdev definition of storage splits up a storage into a protocol node, which handles storage access: In this case it's a 'file':> ... -blockdev > {"driver":"file","filename":"/var/lib/libvirt/images/new.qcow2","node-name":"libvirt-2-storage","auto-read-only":true, > *"discard":"unmap"*}You can see, that 'discard: unmap' is enabled only here. The second layer is a 'format' node which handles the actual qcow2 format:>-blockdev > {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}Here you can see that there's no 'discard' setting, since you didn't configure any setting in the disk. Now the above configuration is used as we want to allow the QCOW2 driver to discard it's unused internal sectors/structures. This can happen for example when you delete an internal snapshot. All the unused sectors get unref'd and discarded. This wouldn't be possible without enabling unmap for the protocol node and the qcow2 image would not decrease size otherwise. The user setting is configured only for the 'format' node since it handles whether the guest discard gets honoured or not. The 'format' node is then installed as the disk backend:> -device > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1[...]> I think it's from > https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_block.c#L1211 > But I cannot find the reason from commit msgs or documents. > Could you please explain it?See above. I'm curious though why are you asking? You didn't mention that there's any problem with that.
On Thu, Oct 22, 2020 at 2:40 PM Peter Krempa <pkrempa@redhat.com> wrote:> On Thu, Oct 22, 2020 at 10:57:05 +0800, Han Han wrote: > > Hello, > > I find "discard":"unmap" is defaultly enabled in qemu cmdline(libvirt > > v6.6, qemu v5.1): > > XML: > > <disk type="file" device="disk"> > > <driver name="qemu" type="qcow2"/> > > <source file="/var/lib/libvirt/images/new.qcow2" index="2"/> > > <backingStore/> > > <target dev="sda" bus="scsi"/> > > <alias name="scsi0-0-0-0"/> > > <address type="drive" controller="0" bus="0" target="0" unit="0"/> > > [...] > > > QEMU cmdline: > > The -blockdev definition of storage splits up a storage into a protocol > node, which handles storage access: > > In this case it's a 'file': > > > ... -blockdev > > > {"driver":"file","filename":"/var/lib/libvirt/images/new.qcow2","node-name":"libvirt-2-storage","auto-read-only":true, > > *"discard":"unmap"*} > > You can see, that 'discard: unmap' is enabled only here. > > > The second layer is a 'format' node which handles the actual qcow2 > format: > > >-blockdev > > > {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} > > Here you can see that there's no 'discard' setting, since you didn't > configure any setting in the disk. > > Now the above configuration is used as we want to allow the QCOW2 driver > to discard it's unused internal sectors/structures. This can happen for > example when you delete an internal snapshot. All the unused sectors get > unref'd and discarded. This wouldn't be possible without enabling unmap > for the protocol node and the qcow2 image would not decrease size > otherwise. > > The user setting is configured only for the 'format' node since it > handles whether the guest discard gets honoured or not. > > The 'format' node is then installed as the disk backend: > > Thx> > -device > > > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1 > > [...] > > > > I think it's from > > > https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_block.c#L1211 > > But I cannot find the reason from commit msgs or documents. > > Could you please explain it? > > See above. I'm curious though why are you asking? You didn't mention > that there's any problem with that. > > Yeah. No problems here. I was just a little surprised to find discard inqemu cmdline when no such configurations in libvirt domain XML.