qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] iSCSI support for QEMU


From: ronnie sahlberg
Subject: Re: [Qemu-devel] iSCSI support for QEMU
Date: Thu, 21 Apr 2011 21:12:19 +1000

On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
> <address@hidden> wrote:
>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <address@hidden> 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
* this test we are talking about is for READ10,   reads, not writes.


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.



regards
ronnie sahlberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]