All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.