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