From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtK6q-0006yd-9J for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:32:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtK6j-0000HN-8I for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:32:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtK6i-0000HI-Ve for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:31:53 -0500 Message-ID: <50EEDEE2.80900@redhat.com> Date: Thu, 10 Jan 2013 16:31:46 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <50EC0D41.4070200@redhat.com> <50EC1C9A.5040006@gmail.com> <50ED45A8.5020706@redhat.com> <50ED4829.1070302@gmail.com> <50ED4933.3040001@redhat.com> <50ED4A90.2080808@gmail.com> <50ED5D64.4040600@gmail.com> <50ED65AA.60000@redhat.com> <50ED6AF4.4060300@gmail.com> <50ED8868.6010805@redhat.com> <20130110152535.GD21483@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20130110152535.GD21483@jl-vm1.vm.bytemark.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Kevin Wolf , Liu Yuan , qemu-devel@nongnu.org, MORITA Kazutaka , Stefan Hajnoczi Il 10/01/2013 16:25, Jamie Lokier ha scritto: >> > Perhaps it's a bug that the cache mode is not reset when the machine is >> > reset. I haven't checked that, but it would be a valid complaint. > The question is, is cache=writeback/cache=writethrough an initial > setting of guest-visible WCE that the guest is allowed to change, or > is cache=writeththrough a way of saying "don't have a write cache" > (which may or may not be reflected in the guest-visible disk id). It used to be the latter (with reflection in the disk data), but now it is the former. > I couldn't tell from QEMU documentation which is intended. It would > be a bit silly if it means different things for different backend > storage. It means the same thing for IDE, SCSI and virtio-blk. Other backends, such as SD, do not even have flush, and are really slow with cache=writethrough because they write one sector at a time. For this reason they cannot really be used in a "safe" manner. > I have seen (obscure) guest code which toggled WCE to simulate FUA, That's quite useless, since WCE=1->WCE=0 is documented to cause a flush (and it does). Might as well send a real flush. > and there is plenty of advice out there saying to set WCE=0 for > certain kinds of databases because of its presumed crash safety. Even > very ancient guests on Linux and Windows can change WCE=0 with IDE and > SCSI. This is supported in QEMU. > So from a guest point of view, I think guest setting WCE=0 should mean > exactly the same as FUA every write, or flush after every write, until > guest setting WCE=1. Yes, that's indeed how it is implemented. Paolo