From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsXTG-0005Bo-Ci for qemu-devel@nongnu.org; Tue, 08 Jan 2013 06:35:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsXTF-0002nB-B1 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 06:35:54 -0500 Received: from mail-pb0-f44.google.com ([209.85.160.44]:57028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsXTE-0002n2-T2 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 06:35:53 -0500 Received: by mail-pb0-f44.google.com with SMTP id uo1so194014pbc.31 for ; Tue, 08 Jan 2013 03:35:52 -0800 (PST) Message-ID: <50EC0493.8030701@gmail.com> Date: Tue, 08 Jan 2013 19:35:47 +0800 From: Liu Yuan 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> In-Reply-To: <50EC00CE.80205@redhat.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: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, MORITA Kazutaka , Paolo Bonzini On 01/08/2013 07:19 PM, Kevin Wolf wrote: > I can't see a reason why it would do that. Can you bisect this? > Sure, bisect it is on my schedule, but I can't promise a deadline. >>>> >>> It seems it is hard to restore into old semantics of cache flags due to >>>> >>> new design of QEMU block layer. So will you accept that adding a 'flags' >>>> >>> into BlockDriverState which carry the 'cache flags' from user to keep >>>> >>> backward compatibility? >>> >> >>> >> No, going back to the old behaviour would break guest-toggled WCE. >>> >> >> > >> > Guest-toggled WCE only works with IDE and seems that virtio-blk doesn't >> > support it, no? And I think there are huge virtio-blk users. > It works with virtio-blk and SCSI as well. > Okay, I see the code indeed support WCE but it requires Guest kernel to support it. For the kernel doesn't support it, there is no way to disable write cache, no? >> > I didn't meant to break WCE. What I meant is to allow backward >> > compatibility. For e.g, Sheepdog driver can make use of this dedicated >> > cache flags to implement its own cache control and doesn't affect other >> > drivers at all. > How would you do it? With a WCE that changes during runtime the idea of > a flag that is passed to bdrv_open() and stays valid as long as the > BlockDriverState exists doesn't match reality any more. I am not sure if I get it right. What I meant is allow Sheepdog to control cache on the 'cache flags' at startup and ignore WCE on the run time. So you mean, if I choose witeback cache at startup, and then Guest disable it via WCE, then block layer will never send flush request down to Sheepdog driver? Thanks, Yuan