Comment 13 for bug 1974100

Hmm,
interesting - here our results differ then.

All of my 8 attachments do not have that problem.
"debugfs -R dump_unused" does not report anything and zerofree agrees reporting all of them as "none to modify/free" / "almost all is free" / "total blocks"

example:
$ sudo zerofree -vn /dev/sdd
0/6406707/6553600

Have you run any else to get debugfs/zerofree to show this in your case, or does that even show with the simplified repro in comment #7?

Furthermore I was trying to separate this from the base cloud-image - so all my tests are on new qemu images + mkfs.ext4. Could it be that you see that behavior only on the base image that had content and is extended?

I was looking at this theory (only a problem of the extended base cloud image) by attaching them to nbd in the host after guest shutdown.

zerofree on:
new image / mkfs.ext4 via virtio - 0/6406451/6553344
new image / mkfs.ext4 via ide/sata - 0/6406707/6553600
cloud image / resize2fs via virtio - 4381/1631019/2068731

So indeed I have some (but not much ~17Mb) crap on the latter.
But the amount could as well be from padding the image in the first place on creation.

I do not have your combination (as I'd never use the old disk type for my root and all tools that make it easy for me to deploy one also pick virtio by default), but I assume that your case
"cloud image / resize2fs via ide/sata" might be even worse since (as shown above) you'd also need active zero detection to work out better.

@Brent, could you please confirm me that you also only see that problem on the extended cloud-image and not on otherwise new/fresh disks?