Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort

[Stefan Priebe - Profihost AG <s.priebe@profihost.ag>]

Am 21.08.2012 00:36, schrieb ronnie sahlberg:
> On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG
> <s.priebe@profihost.ag> 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.

How is this relevant to the fact, that i can't even work with SSH any 
longer with paolo's patch while UNMAPs are running? With my patchset you 
can still work on the machine.

Greets,
Stefan