[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Nbd] (QEmu-)NBD and discard/TRIM


I've been using qemu-nbd with a 512Mbyte qcow2 disk image and I ran into

# blkdiscard  /dev/nbd0 
blkdiscard: /dev/nbd0: BLKDISCARD ioctl failed: Input/output error
# dmesg | tail -2
[1455221.427688] block nbd0: Other side returned error (22)
[1455221.428733] blk_update_request: I/O error, dev nbd0, sector 0

Looking in /sys shows the following:
# cat /sys/block/nbd0/queue/discard_max_bytes 

says the following:
		blk_queue_max_discard_sectors(disk->queue, UINT_MAX);

(Using the value from http://tigcc.ticalc.org/doc/limits.html#UINT_MAX ,
UINT_MAX * 512 is going to be 2199023255040)

However I don't believe QEmu supports discard's that big:

Forcing blkdiscard to send (much) smaller batches works:
blkdiscard -p 33554432 /dev/nbd0
# echo $?

(33554432 is 2^25)

Further, re-running qemu-nbd with -v says this:
nbd.c:nbd_co_receive_request():L1232: len (536870912) is larger than max len (33554432)
which comes from https://github.com/qemu/qemu/blob/v2.5.0/nbd.c#L1230 :
    if (request->len > NBD_MAX_BUFFER_SIZE) {
        LOG("len (%u) is larger than max len (%u)",
            request->len, NBD_MAX_BUFFER_SIZE);
        rc = -EINVAL;
        goto out;
NBD_MAX_BUFFER_SIZE is defined in
https://github.com/qemu/qemu/blob/v2.5.0/include/block/nbd.h#L73 :
/* Maximum size of a single READ/WRITE data buffer */
#define NBD_MAX_BUFFER_SIZE (32 * 1024 * 1024)

In this particular case the real request is probably far smaller than it
looks because we aren't individual data for each LBA...

If max discard sectors has to be hard coded on NBD clients, perhaps the
kernel code should be changed to always limit the size to 0xFFFF rather
than using UINT_MAX (this will stop it varying by platform)?
Alternatively a more flexible solution might be to allow the NBD server
to tell the NBD client the maximum number of discard sectors it can pass
à la SCSI...

Sitsofe | http://sucs.org/~sits/

Reply to: