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