On 05/10/2016 10:33 AM, Quentin Casasnovas wrote: > Looks like there's an easier way: > > $ qemu-img create -f qcow2 foo.qcow2 10G > $ qemu-nbd --discard=on -c /dev/nbd0 foo.qcow2 > $ mkfs.ext4 /dev/nbd0 > mke2fs 1.42.13 (17-May-2015) > Discarding device blocks: failed - Input/output error strace on mkfs.ext4 shows: ... open("/dev/nbd1", O_RDWR|O_EXCL) = 3 stat("/dev/nbd1", {st_mode=S_IFBLK|0660, st_rdev=makedev(43, 1), ...}) = 0 ioctl(3, BLKDISCARDZEROES, [0]) = 0 ioctl(3, BLKROGET, [0]) = 0 uname({sysname="Linux", nodename="red", ...}) = 0 ioctl(3, BLKDISCARD, [0, 1000000]) = 0 write(1, "Discarding device blocks: ", 26) = 26 write(1, " 4096/2621440", 15 4096/2621440) = 15 write(1, "\10\10\10\10\10\10\10\10\10\10\10\1) = 15 ioctl(3, BLKDISCARD, [1000000, 80000000]) = -1 EIO (Input/output error) write(1, " ", 15 ) = 15 write(1, "\10\10\10\10\10\10\10\10\10\10\10\1) = 15 write(1, "failed - ", 9failed - ) = 9 so it does indeed look like the smaller request [0, 0x1000000] succeeded while the larger [0x1000000, 0x80000000] failed with EIO. But I instrumented my qemu-nbd server to output all of the incoming requests it was receiving from the kernel, and I never saw a mention of NBD_CMD_TRIM being received. Maybe it's dependent on what version of the kernel and/or NBD kernel module you are running? I also tried fallocate(1) on /dev/nbd1, as in: # strace fallocate -o 0 -l 64k -p /dev/nbd1 but it looks like the kernel doesn't yet wire up fallocate(2) to forward to the appropriate device ioctls and/or NBD_CMD_TRIM, where strace says: open("/dev/nbd1", O_RDWR) = 3 fallocate(3, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 0, 65536) = -1 ENODEV (No such device) The ENODEV is a rather unusual choice of error. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature