From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsuzD-0004Yp-8l for qemu-devel@nongnu.org; Wed, 09 Jan 2013 07:42:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsuzB-0006Pv-VR for qemu-devel@nongnu.org; Wed, 09 Jan 2013 07:42:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsuzB-0006Pj-MZ for qemu-devel@nongnu.org; Wed, 09 Jan 2013 07:42:25 -0500 Message-ID: <50ED65AA.60000@redhat.com> Date: Wed, 09 Jan 2013 13:42:18 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1355941771-3418-1-git-send-email-namei.unix@gmail.com> <87k3s6shdv.wl%morita.kazutaka@lab.ntt.co.jp> <50D967C3.7020109@gmail.com> <50E58B19.2050701@gmail.com> <20130104163830.GF6310@stefanha-thinkpad.hitronhub.home> <50E7AEC4.5080309@gmail.com> <50E7BA41.3020307@gmail.com> <50E7DC9B.4080309@gmail.com> <50EACC61.2020603@redhat.com> <50EBB1CB.9030608@gmail.com> <20130108094025.GE2557@stefanha-thinkpad.redhat.com> <50EBEAD2.6070608@gmail.com> <50EBEE42.7010407@redhat.com> <50EBF755.3050607@gmail.com> <50EBFA3F.8030808@redhat.com> <50EBFE20.9010100@gmail.com> <50EC00CE.80205@redhat.com> <50EC0493.8030701@gmail.com> <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> In-Reply-To: <50ED5D64.4040600@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Liu Yuan Cc: Paolo Bonzini , qemu-devel@nongnu.org, MORITA Kazutaka , Stefan Hajnoczi Am 09.01.2013 13:07, schrieb Liu Yuan: > Besides performance, I think backward compatibility is more important: > 1 if we run a old kernel host (quite possible for a long running > server) which doesn't support WCE, then we will never have a chance to > choose writethrough cache for guest OS against new QEMU (most users tend > to update user space tools to exclude bugs) How does the host kernel even play a role in this context? > 2 The upper layer software which relies on the 'cache=xxx' to choose > cache mode will fail its assumption against new QEMU. Which assumptions do you mean? As far as I can say the behaviour hasn't changed, except possibly for the performance. > We can see that the writeback behavior for Guest-WCE toggling is the > same as expected. The difference is that if we set cache=writethrough, > guest can't change it via WCE toggling. Then you need to make sure to communicate this to the guest. I'm not convinced that adding extra logic to each device for this is a good idea. Kevin