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? Thanks, Yuan