qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
>

  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).