From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsZ4U-0008W7-BV for qemu-devel@nongnu.org; Tue, 08 Jan 2013 08:18:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsZ4S-0003PV-QK for qemu-devel@nongnu.org; Tue, 08 Jan 2013 08:18:26 -0500 Received: from mail-pb0-f47.google.com ([209.85.160.47]:57464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsZ4S-0003PM-H1 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 08:18:24 -0500 Received: by mail-pb0-f47.google.com with SMTP id un1so243630pbc.6 for ; Tue, 08 Jan 2013 05:18:23 -0800 (PST) Message-ID: <50EC1C9A.5040006@gmail.com> Date: Tue, 08 Jan 2013 21:18:18 +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> <50EC0493.8030701@gmail.com> <50EC0D41.4070200@redhat.com> In-Reply-To: <50EC0D41.4070200@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 08:12 PM, Kevin Wolf wrote: > Ok, thanks. It would be good if it was before the hard freeze for 1.4. > Oops, sorry. It is a false alarm. Last time I was running latest QEMU on tmpfs which service the request too fast. >>>>>>>>> >>>>>>>> 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? > With Linux guests, it's possible for SCSI. I'm not sure about > virtio-blk, but you might be right that you can't manually change it there. > >>>>> >>>> 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. > If you start with cache=writeback and then the guests switches WCE off > and you ignore that, then you're causing data corruption in the case of > a crash. This is not an option. > >> > 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? > Yes, this is the problematic case. Currently the qemu block layer makes > sure to send flushes, but if you disable that logic for Sheepdog, you > would get broken behaviour in this case. Maybe not for a second thought. See following combination: cache flags WCE toggled and resulting behavior writethrough writethrough writeback writetrhough (writeback + flush as expected) cache flags means specify 'cache=xxx' at startup and WCE toggled on the fly in the guest (supose guest kernel support WCE control) So the result is *not* broken. If we set cache=writethrough for sheepdog, then WCE won't take any effect because 'flush' request will be ignored by Sheepdog driver. And with cache=writeback, WCE does disable the writecache and actually turns it to a writethrough cache by sending flush req every time for write. To conclude, let Sheepdog interpret cache flags won't cause trouble even with current Guest WCE feature, the different is that if we set cache=writethrough, guest can't change it via WCE toggling. Is this behavior acceptable? Thanks, Yuan