From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Virtbie <virtbie@shiftmail.org>
Subject: Re: [Qemu-devel] Is cache=writeback safe yet?
Date: Mon, 20 Feb 2012 18:03:58 +0100 [thread overview]
Message-ID: <4F427CFE.7050907@redhat.com> (raw)
In-Reply-To: <CAFEAcA-rHYU0gKMSGWP6FD551in5SeZtzH64mH+ay=2jyj416g@mail.gmail.com>
On 02/20/2012 05:08 PM, Peter Maydell wrote:
> On 20 February 2012 15:56, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 20.02.2012 16:29, schrieb Peter Maydell:
>>> The thing that confuses me when this subject comes up is that "cache=writeback"
>>> is a property of the block layer, but the WCE flag is a SCSI parameter,
>>> right? How does this work on non-SCSI disks? Is there something that
>>> eg hw/sd.c should be doing to tell the block layer "writeback cache is
>>> safe/unsafe" ?
>>
>> IDE and virtio-blk have some kind of WCE bit as well.
>>
>> If your hardware doesn't have it, I think you need to check whether your
>> hardware never has any write cache or if it always has one (if it
>> sometimes has one but doesn't expose the information, it's already the
>> hardware that is broken).
>
> The nature of the SD card protocol is that you feed a 512 byte block
> to the thing and when it's written it's written. (The best you can do
> is that some cards support feeding one block to the card while it's
> still digesting the previous block; we don't emulate this in QEMU
> though.)
You need to send a bdrv_flush after each write then.
>> You should probably just fail device creation with an inappropriate
>> cache option.
>
> The trouble with that idea is that it's slower, so you want to give the
> user the option of saying "go fast and I accept data loss if my host
> kernel crashes"...
That's cache=unsafe.
> Also it seems to me that it would be a cleaner API for the sd/ide/scsi
> layers to tell the block layer what their capabilities are and have the
> block layer fail the device creation if that doesn't match with the
> user's requests.
I think it's not necessary. Just fix SD to always be safe, and the user
will still have the option to make it fast with cache=unsafe. Unless
they manually set cache=none users won't notice the difference anyway,
because the default is cache=writethrough and it already does a flush
after each write.
Paolo
next prev parent reply other threads:[~2012-02-20 17:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 14:18 [Qemu-devel] Is cache=writeback safe yet? Virtbie
2012-02-20 15:06 ` Anthony Liguori
2012-02-20 15:43 ` Virtbie
2012-02-20 17:52 ` Virtbie
2012-02-20 15:20 ` Kevin Wolf
2012-02-20 15:29 ` Peter Maydell
2012-02-20 15:56 ` Kevin Wolf
2012-02-20 16:08 ` Peter Maydell
2012-02-20 17:03 ` Paolo Bonzini [this message]
2012-02-20 17:10 ` Peter Maydell
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=4F427CFE.7050907@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=virtbie@shiftmail.org \
/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).