Re: [Qemu-devel] iSCSI support for QEMU

[ronnie sahlberg <ronniesahlberg@gmail.com>]

On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <hch@lst.de> wrote:
>> In my patch, there are NO data integrity issues.
>> Data is sent out on the wire immediately as the guest issues the write.
>> Once the guest issues a flush call, the flush call will not terminate
>> until the SYNCCACHE10 task has completed.
>
> No guest will even issue a cache flush, as we claim to be WCE=0 by default.
> Now if you target has WCE=1 it will cache data internally, and your
> iscsi initiator will never flush it out to disk.

My target does not do any caching at all.
It happily ignores both FUA and FUA_NV bits and always destage all
data to stable storage before
sending SCSI_STATUS_GOOD back to the initiator.

I use the same target and the same LUN and the same settings for both testing
QEMU+openiscsi-mounted-lun   and QEMU+libiscsi

I do not understand why my target would have data integrity problem
when used with libiscsi
but not with open-iscsi mounted lun?


>
> 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 think this discussion is strange. I would like discussion about the
merits of my patch and if features like built-in
iscsi support that enterprise users find useful are desireable in
QEMU. I do not find discussions about semantics of
my particular iscsi target to be meaningful for that purpose.



regards
ronnie sahlberg