On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG
<address@hidden> wrote:
Hi Ronnie,
Am 20.08.2012 10:08, schrieb Paolo Bonzini:
That's because the "big QEMU lock" is held by the thread that called
qemu_aio_cancel.
and i also see
no cancellation message in kernel log.
And that's because the UNMAP actually ultimately succeeds. You'll
probably see soft lockup messages though.
The solution here is to bump the timeout of the UNMAP command (either in
the kernel or in libiscsi, I didn't really understand who's at fault).
What's your suggestion / idea about that?
There are no timeouts in libiscsi itself.
But you can probably tweak it through the guest kernel :
$ cat /sys/bus/scsi/devices/0\:0\:0\:0/timeout
30
should be the default scsi timeout for this device, and
$ cat /sys/bus/scsi/devices/0\:0\:0\:0/queue_depth
31
would be how many concurrent i/o that the guest will drive to the device.
When performing the UNMAPS, maybe setting timeout to something really
big, and at the same time also dropping queue-depth to something
really small so that the guest kernel will not be able to send so many
UNMAPs concurrently.