On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <h...@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