I haven't come across this before. Our builds for the cloud images from
cloud-images.ubuntu.com have the following cleanup code run that should
be preventing this sort of thing:
https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n231
hard to read exact ramifications, but the gist
Hi Brent,
> can you run qemu from the command line on a bare metal system? If so,
I thought my May 20 procedure was pretty simple.
Oh yes you can run it from cli on bare metal - and your procedure was
indeed simple and very useful. I was not trying to challenge any of that
- sorry if that was
@Christian,
I haven't tried all of your combinations, but when I mount a second disk
using the growpart/e2fsck/resize2fs sequence that you suggest and then
mount it, it grows to 725 MB and then zerofree reports what you
observed:
baccala@osito:~/NPDC/GNS3/bug$ sudo zerofree -v /dev/nbd0p1
# I have fetched a new cloud image.
$ wget
https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img
$ file jammy-server-cloudimg-amd64-disk-kvm.img
jammy-server-cloudimg-amd64-disk-kvm.img: QEMU QCOW2 Image (v2), 2361393152
bytes
# Then I have extended it to 25G
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
@Christian - my lsblk output looks very similar to yours. In
particular, all device types are reporting discard support; the only
difference is the reported discard sizes.
I would suggest that at the end of your tests you check the disk with
"debugfs -R dump_unused". I'm seeing disk blocks
@Brent - Let me know if your data and/or lsblk/dump2fs look vastly
different?
I pondered if I should call this "a feature request to an old attachment type"
which is unlikely
to get much attention. But the only stomach-ache that I have with this (and
this is why I do not close this) is that it
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
