From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsBrO-0006A1-UG for qemu-devel@nongnu.org; Mon, 07 Jan 2013 07:31:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsBrN-0007d7-CM for qemu-devel@nongnu.org; Mon, 07 Jan 2013 07:31:22 -0500 Received: from mail-bk0-f50.google.com ([209.85.214.50]:52257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsBrN-0007cz-4q for qemu-devel@nongnu.org; Mon, 07 Jan 2013 07:31:21 -0500 Received: by mail-bk0-f50.google.com with SMTP id jf3so8323230bkc.9 for ; Mon, 07 Jan 2013 04:31:20 -0800 (PST) Date: Mon, 7 Jan 2013 13:31:17 +0100 From: Stefan Hajnoczi Message-ID: <20130107123117.GA17997@stefanha-thinkpad.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E7DC9B.4080309@gmail.com> 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: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, MORITA Kazutaka On Sat, Jan 05, 2013 at 03:56:11PM +0800, Liu Yuan wrote: > On 01/05/2013 01:29 PM, Liu Yuan wrote: > > On 01/05/2013 12:40 PM, Liu Yuan wrote: > >> On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote: > >>> Hi Yuan, > >>> BDRV_O_NOCACHE means bypass host page cache (O_DIRECT). > >>> > >>> BDRV_O_CACHE_WB specifies the cache semantics that the guest sees - that > >>> means whether the disk cache is writethrough or writeback. > >>> > >>> In other words, BDRV_O_NOCACHE is a host performance tweak while > >>> BDRV_O_CACHE_WB changes the cache safety of the BlockDriverState. A > >>> protocol driver like sheepdog doesn't need to look at BDRV_O_CACHE_WB > >>> because it is implemented in block.c (see bdrv_co_do_writev() where QEMU > >>> will flush when after each write when !bs->enable_write_cache). > >> > >> Hi Stefan, > >> > >> Thanks for your explanation. But after more investigation, I find > >> myself more confused: > >> > >> flags passed from block layer > >> {writeback, writethrough} 0x2042 > >> {directsync, off, none} 0x2062 > >> {unsafe} 0x2242 > >> > >> So underlying driver like Sheepdog can't depend on 'flags' passed from > >> .bdrv_file_open() to choose the right semantics (This was possible for > >> old QEMU IIRC). > >> > >> If we can't rely on the 'flags' to get the cache indications of users, > >> would you point me how to implement tristate cache control for network > >> block driver like Sheepdog? For e.g, I want to implement following > >> semantics: > >> cache=writeback|none|off # enable writeback semantics for write > >> cache=writethrough # enable writethrough semantics for write > >> cache=directsync # disable cache completely > >> > >> Thanks, > >> Yuan > >> > > > > I tried the old QEMU and v1.1.0 and v1.1.2, they still worked as I > > expected. So I guess generic block layer got changed a bit and the > > 'flags' meaning turned different than old code, which did indeed allow > > block drivers to interpret the 'flags' passed from bdrv_file_open(). > > > > With the current upstream code, it seems that BDRV_O_CACHE_WB is always > > enabled and makes 'flags' completely unusable for block drivers to get > > the indications of user by specifying 'cache=' field. > > > > So is there other means to allow block drivers to rely on, in order to > > interpret the 'cache semantics'? > > > > I found the commit:e1e9b0ac 'always open drivers in writeback mode'. > This is really undesired for network block drivers such as Sheepdog, > which implement its own cache mechanism that support > writeback/writethrough/directio behavior and then want to interpret > these flags on its own. > > Is there any means for block drivers to get the semantics of 'cache=xxx' > from users? Hi Yuan, Please explain what cache semantics the sheepdog server supports so I can understand better what you are trying to achieve. Stefan