Re: [Qemu-devel] iSCSI support for QEMU

[Stefan Hajnoczi <stefanha@gmail.com>]

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?

Stefan