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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs