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
signature.asc
Description: OpenPGP digital signature
