Re: [Qemu-devel] iSCSI support for QEMU

[ronnie sahlberg]

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 <address@hidden> 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.
>
>