Please re-read my post or read the patch. It has O_DIRECT like behaviour in that it will not pollute the hosts cache. This for the simple reason that the host is not aware that there is any block i/o happening.
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. I do not have any cache at all in libiscsi or the patch. All I/O are always sent to the iSCSI target. No data is ever cached anywhere. I am just saying that in the tests I did, I had to use 'cache=none,aio=native' to come anywhere near the libiscsi performance. All other options performed significantly worse. I have no idea what those options have for effect on data integrity or open-iscsi. There should not be any integrity issues in libiscsi since it does not cache at all, ever. regards ronnie sahlberg On Thu, Apr 21, 2011 at 6:50 PM, Christoph Hellwig <h...@lst.de> wrote: > On Thu, Apr 21, 2011 at 06:43:10PM +1000, Ronnie Sahlberg wrote: >> Some basic tests thatve been performed show it to be significantly faster >> than an out-of-the-box open-iscsi mounted LUN being accessed by default >> QEMU i/o options. > > Which isn't a useful comparism. qemu's default is the braindead > cache=writethrough behaviour, which forces writes out to disk, and bloats the > pagecache, while your mail sounds you silently always implement O_DIRECT-like > semantics. > > Also the implementation has data integrity issues due this. It does > not actually force writes out to disk in the default cache mode, despite > qemu claiming to have WCE=0 in the default mode, i.e. you never flush > the cache. You'll need set the FUA bits on all writes if cache=writethrough > is used, with a fallback to a real cache flush in case the target doesn't > support the FUA bit. > >
