Hmm, carrying on further, with the nbd-client connection, I'm seeing that the kernel DID break things into two separate BLKDISCARD calls, as seen from the nbdkit side of things:
# from the blkdiscard strace: ioctl(3, BLKGETSIZE64, [5368709120]) = 0 ioctl(3, BLKSSZGET, [512]) = 0 ioctl(3, BLKDISCARD, [0, 5368709120]) = 0 # from the nbdkit debug log: nbdkit: memory.0: debug: memory: trim count=4294966784 offset=0 fua=0 nbdkit: memory.3: debug: memory: trim count=1073742336 offset=4294966784 fua=0 I'm now comparing the set of ioctl calls made by nbd-client vs. qemu-nbd to see what might explain the difference for why it worked with nbd- client when the two different servers connect to the kernel nbd.ko module. In the meantime, since nbd-client worked but qemu-nbd did not, it does look like this may be qemu's problem after all. ** Project changed: nbd => qemu -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1884831 Title: qemu-nbd fails to discard bigger chunks Status in QEMU: New Bug description: This report is moved from systemd to here: https://github.com/systemd/systemd/issues/16242 A qemu-nbd device reports that it can discard a lot of bytes: cat /sys/block/nbd0/queue/discard_max_bytes 2199023255040 And indeed, discard works with small images: $ qemu-img create -f qcow2 /tmp/image.img 2M $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img $ sudo blkdiscard /dev/nbd0 but not for bigger ones (still smaller than discard_max_bytes): $ qemu-img create -f qcow2 /tmp/image.img 5G $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img $ sudo blkdiscard /dev/nbd0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1884831/+subscriptions
