Stephan, I understand.
Let me re-send a patch tomorrow that can optionally enable/force FUA bits for write. There are some high-volume arrays that advertise support but fail any cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. regards ronnie sahlberg On Thu, Apr 21, 2011 at 9:21 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg > <ronniesahlb...@gmail.com> wrote: >> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >>> 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? >> >> 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 >