[Request]: re-enable`fstrim` support

[Tarzno]

Feature or enhancement request details

This request of fstrim support was written with the help of an AI:

Summary

fstrim worked correctly inside containers in v0.6.0 but fails in v0.12.3. The root cause is that VIRTIO_BLK_F_DISCARD is no longer being advertised by the host on the rootfs virtio-blk device, so the guest kernel never enables the FITRIM path.

Steps to reproduce

1. Create and start a container (tested with Debian)
2. Inside the container, run:

   fstrim -v /
   

Expected behavior

fstrim completes successfully and reports trimmed bytes, as it did in v0.6.0.

Actual behavior

fstrim: /: FITRIM ioctl failed: Operation not permitted

Diagnosis

The boot log shows no discard-related features negotiated on vdb (the rootfs block device):

container logs --boot debian | grep -iE "virtio|feature|discard|blk"
[    0.076471] virtio_blk virtio2: 1/0/0 default/read/poll queues
[    0.076638] virtio_blk virtio2: [vda] 1048576 512-byte logical blocks (537 MB/512 MiB)
[    0.076904] virtio_blk virtio3: 1/0/0 default/read/poll queues
[    0.077068] virtio_blk virtio3: [vdb] 1073741824 512-byte logical blocks (550 GB/512 GiB)

Inside the container, the discard queue attribute is entirely absent:

# cat /sys/block/vdb/queue/discard_granularity
cat: /sys/block/vdb/queue/discard_granularity: No such file or directory

This confirms that VIRTIO_BLK_F_DISCARD is not being negotiated between host and guest. The sysfs discard attributes would be present (with value 0 or higher) if the feature were offered at all.

Practical impact

The rootfs is stored on the host as a sparse file (rootfs.ext4). Without discard support, freed blocks inside the container cannot be punched back as holes in the sparse file. As a result:

• The sparse file's allocated size grows monotonically and never shrinks, even when files are deleted inside the container
• macOS Finder reads the full logical size of the sparse file (~550 GB) rather than the actual allocated size (~1 GB in this case), and subtracts this from reported free disk space
• This causes Finder to incorrectly refuse file copy operations even when ample real disk space is available

Version information

• Working: v0.6.0
• Broken: v0.12.3 (versions in between not tested)
• Host: macOS Tahoe 26.5
• Guest: Debian 13 (trixie)

Request

Please re-enable VIRTIO_BLK_F_DISCARD on the rootfs virtio-blk device. This feature is essential for keeping sparse image files compact over time and for correct free space reporting on the host.

Code of Conduct

• I agree to follow this project's Code of Conduct