From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzWeo-0007y7-Hl for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:04:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzWek-0003JJ-BO for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:04:10 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:44169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzWek-0003JF-66 for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:04:06 -0500 Received: by dadp14 with SMTP id p14so7365021dad.4 for ; Mon, 20 Feb 2012 09:04:05 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F427CFE.7050907@redhat.com> Date: Mon, 20 Feb 2012 18:03:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4F425643.2@shiftmail.org> <4F4264B5.6040206@redhat.com> <4F426D45.9080109@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Is cache=writeback safe yet? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , qemu-devel@nongnu.org, Virtbie On 02/20/2012 05:08 PM, Peter Maydell wrote: > On 20 February 2012 15:56, Kevin Wolf 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