Re: [Qemu-devel] iSCSI support for QEMU

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg
<ronniesahlberg@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
>> <ronniesahlberg@gmail.com> wrote:
>>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <hch@lst.de> 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