From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] iSCSI support for QEMU
Date: Thu, 21 Apr 2011 21:36:12 +1000 [thread overview]
Message-ID: <BANLkTikpghHCNFr5NbYLoUw+Z55rDvH+Sg@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinFeUNg25hSfWLX8jDp_pgfsrvTQw@mail.gmail.com>
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 <stefanha@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg
> <ronniesahlberg@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
>>> <ronniesahlberg@gmail.com> wrote:
>>>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig <hch@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
>
next prev parent reply other threads:[~2011-04-21 11:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 8:43 [Qemu-devel] iSCSI support for QEMU Ronnie Sahlberg
2011-04-21 8:43 ` [Qemu-devel] [PATCH] iSCSI block driver support Ronnie Sahlberg
2011-04-21 8:50 ` [Qemu-devel] iSCSI support for QEMU Christoph Hellwig
2011-04-21 8:58 ` ronnie sahlberg
2011-04-21 9:09 ` Christoph Hellwig
2011-04-21 9:28 ` ronnie sahlberg
2011-04-21 10:58 ` Stefan Hajnoczi
2011-04-21 11:12 ` ronnie sahlberg
2011-04-21 11:21 ` Stefan Hajnoczi
2011-04-21 11:36 ` ronnie sahlberg [this message]
2011-04-21 11:44 ` Kevin Wolf
2011-04-21 12:08 ` Stefan Hajnoczi
2011-04-21 12:49 ` Christoph Hellwig
2011-04-21 20:25 ` ronnie sahlberg
2011-04-21 9:47 ` ronnie sahlberg
-- strict thread matches above, loose matches on Subject: below --
2011-06-12 2:54 ronnie sahlberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTikpghHCNFr5NbYLoUw+Z55rDvH+Sg@mail.gmail.com \
--to=ronniesahlberg@gmail.com \
--cc=hch@lst.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).