qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] iSCSI support for QEMU


From: ronnie sahlberg
Subject: Re: [Qemu-devel] iSCSI support for QEMU
Date: Thu, 21 Apr 2011 21:36:12 +1000

Stephan,

I understand.

Let me re-send a patch tomorrow that can optionally enable/force FUA
bits for write.
There are some high-volume arrays that advertise support but fail any
cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional.


regards
ronnie sahlberg

On Thu, Apr 21, 2011 at 9:21 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg
> <address@hidden> wrote:
>> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi <address@hidden> wrote:
>>> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
>>> <address@hidden> wrote:
>>>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <address@hidden> wrote:
>>>>> We only claim WCE=1 to the guest if cache=writeback or cache=none are
>>>>> set.  So ignoring the issue of having a cache on the initiator side
>>>>> you must implement stable writes for the default cache=writethrough
>>>>> behaviour by either seeting the FUA bit on your writes, or doing
>>>>> a cache flush after every write in case the target does not support FUA.
>>>>
>>>> My target right now does such flushes for writes.
>>>>
>>>>
>>>> I fail to see why FUA, FUA_NV or flushes have any relevance to a test
>>>> that just involves reading data off the lun.
>>>
>>> I'll try to rephrase what Christoph has pointed out.
>>>
>>> When QEMU is run with cache=writethrough (default), QEMU does not
>>> report a write cache on the emulated disk.  The guest believes that
>>> all writes are stable because there is no disk write cache.  Therefore
>>> the guest does not need to issue synchronize cache commands ever.
>>>
>>> In order to meet these semantics with libiscsi, we would need to set
>>> FUA or send a synchronize cache command for every write.  (QEMU's
>>> raw-posix.c file I/O meets these semantics by opening the image file
>>> with O_DSYNC when cache=writethrough.)
>>>
>>>> I do not understand why my target would have data integrity problem
>>>> when used with libiscsi
>>>> but not with open-iscsi mounted lun?
>>>
>>> In the open-iscsi cache=writethrough case, QEMU's raw-posix.c opens
>>> the file with O_DSYNC.  Open-iscsi must set the FUA bit or synchronize
>>> cache for each write request.
>>>
>>> How does libiscsi behave in this case?
>>
>> libiscsi ignores the O_DSYNC flag.
>> It does not matter for two reasons:
>> * my target always destage to disk before replying. I.e. my target
>> ALWAYS write data synchronously to stable storage
>
> Does libiscsi initiator ensure this?  What if I use a different target
> or configure it differently, will libiscsi take care to ensure the
> semantics are still met?
>
>> * this test we are talking about is for READ10,   reads, not writes.
>
> I was not talking about a specific test.
>
>> Serioulsly, please explain,
>> in what exact way are write semantics and FUA bits and write destage
>> policy relevant here :
>>
>> sudo time dd if=/dev/sda of=/dev/null bs=1M
>>
>>
>> I seriously do not understand. Please educate me.
>
> Write semantics are completely independent of this dd read example.
>
> Stefan
>



reply via email to

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