Public bug reported: I encountered this problem using this script to create a GNS3 appliance:
https://github.com/BrentBaccala/NPDC/blob/master/GNS3/ubuntu.py I'm running a stock gns3-server on Ubuntu 18. I called it like this: ./ubuntu.py -r 20 -s $((1024*1024)) --vnc --boot-script opendesktop.sh This uses the Ubuntu 20 server cloudimg to create a new GNS3 appliance with a thin provisioned disk resized to 1024*1024 MB = 1 TB. Although the disk holds less than 5 GB of data once the installation scripts finishes, the qcow2 disk file balloons to over 35 GB, and watching the processes running in the virtual machine shows that the culprit is "ext4lazyinit". I posted a question about this at https://unix.stackexchange.com/questions/700050 Shutting down the instance, mounting the disk using qemu-nbd, and running "debugfs -R dump_unused" on the first partition shows all kind of junk in the unused blocks. Running "zerofree" on the partition shows hundreds of thousands of blocks being zeroed Then using "qemu-img convert -O qcow2" to copy the disk image to another qcow2 file and discard zero blocks reduces its size to 4.3 GB. I tried modifying gns3 to set discard=on option on the qemu command line; this seems to have no effect. Here's an actual qemu command line (called from gns3): /usr/bin/qemu-system-x86_64 -name ubuntu -m 4096M -smp cpus=1,sockets=1 -enable-kvm -machine smm=off -boot order=c -cdrom /home/gns3/GNS3/projects/29706745-5a53-44bf-9313-c8e78089c2f5/29706745-5a53-44bf-9313-c8e78089c2f5_ubuntu.iso -drive file=/home/gns3/GNS3/projects/29706745-5a53-44bf-9313-c8e78089c2f5/project- files/qemu/1deb3b2f-421e-460b-91df- eb36b13d17e9/hda_disk.qcow2,if=ide,index=0,media=disk,id=drive0,discard=on -uuid 1deb3b2f-421e-460b-91df-eb36b13d17e9 -vnc 0.0.0.0:5 -monitor tcp:127.0.0.1:40269,server,nowait -net none -device virtio-net- pci,mac=0c:eb:3b:2f:00:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:20015,localaddr=127.0.0.1:20014 The qemu disk image was created by "qemu-img create", backed by ubuntu-20.04-server-cloudimg-amd64.img, and resizing it with "qemu-img resize". My best guess is that this is a bug in qemu's handling of disk DISCARD operations. ** Affects: ubuntu Importance: Undecided Status: New -- 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: inode lazy init in a VM fills virtual disk with garbage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
