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

[Kevin Wolf]

Am 05.01.2013 08:56, schrieb Liu Yuan:
> 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?

No, and in theory they shouldn't have to care.

Why do you want to handle writethrough semantics in the block driver
rather than letting qemu care for sending the right flushes?

Kevin