Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics

[Stefan Hajnoczi <stefanha@gmail.com>]

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