[Top][All Lists]

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

Re: [Qemu-devel] Is cache=writeback safe yet?

From: Paolo Bonzini
Subject: Re: [Qemu-devel] Is cache=writeback safe yet?
Date: Mon, 20 Feb 2012 18:03:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

On 02/20/2012 05:08 PM, Peter Maydell wrote:
> On 20 February 2012 15:56, Kevin Wolf <address@hidden> 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.


reply via email to

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