Compare:
- 25G qemu images each set to cache=none
- I ide/sata / V = Virtio
- Disk Options:
1 - discard=unmap
2 - discard=unmap + detect_zeroes=on
3 - discard=ignore
4 - defaults
One can check with lsblk --discard (as mentioned above) how the system thinks
it can discard and with dumpe2fs we can check the features used on the fs (I'll
use all defauls and comare it with the cloud image root fs).
Steps:
- Boot system, mkfs.ext4 all of them.
- Gather lsblk and dumpe2fs data.
- Shutdown and check image sizes on host
- Lazy zeroing is done on first mount - check #1 before mount.
- boot, mount, wait for lazy init to complete
- shutdown and check image size again - check #2
lsblk:
They all had the same features reported (even ide/sata)
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
sdb 0 512B 2G 0
sdc 0 512B 2G 0
sdd 0 512B 2G 0
vdc 512 512B 2G 0
vdd 512 512B 2G 0
vde 512 512B 2G 0
vdf 512 512B 2G 0
dump2fs:
Visible options are the same, just "recovery" being set on the cloud image.
Size results:
check #1 check #2
V1 ~10M ~11M
V2 ~10M ~11M
V3 ~10M ~11M
V4 ~10M ~11M
S1 ~140M ~540M
S2 ~10M ~11M
S3 ~140M ~540M
S4 ~140M ~540M
S2 vs S* on both checks we see that just discard doesn't work there as
well as it does on the newer attachment type via virtio.
But - if you need for other reasons - strictly need to get it zeroes in ide one
can use zero detection for ide/sata disks. This can consume cpu time though,
and in general the right way is just to use a more modern disk type (which - as
mentioned before - what all tools & automation usually do for years already).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1974100
Title:
qemu ide/sata disks do not work well with discard/trim
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
