qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races be


From: ronnie sahlberg
Subject: Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort
Date: Tue, 21 Aug 2012 08:36:29 +1000

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.


ronnie s



reply via email to

[Prev in Thread] Current Thread [Next in Thread]