On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg <ronniesahlb...@gmail.com> wrote: > On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <h...@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