Comment 10 for bug 1974100

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).