qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in


From: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Date: Thu, 13 Sep 2012 15:04:18 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

On 09/13/2012 02:56 PM, Paolo Bonzini wrote:
> Il 13/09/2012 19:17, Jeff Cody ha scritto:
>>>>
>>>> Why does this matter?  If raw-posix was opened directly (i.e. without
>>>> the bs->file indirection) this would cause a writethrough file to be
>>>> incorrectly opened as writeback.
>>>>
>>>> Paolo
>>>>
>> The problem this patch was trying to work around is that
>> bdrv_open_common() forces BDRV_O_CACHE_WB (commit e1e9b0ac), but that
>> setting is not preserved in bs->open_flags, so it is lost on a reopen.
> 
> Perhaps we _should_ preserve that in bs->open_flags, while still using
> the initial value of BDRV_O_CACHE_WB to initialize bs->enable_write_cache.

That would work.  Part of the problem is that BDRV_O_CACHE_WB seems
overloaded; maybe bdrv_parse_cache_flags() should set a new flag, called
BDRV_O_CACHE_WCE, which can be used in lieu of enable_write_cache
(similar to getting rid of keep_read_only in favor of
 BDRV_O_ALLOW_RDWR).  And then bdrv_parse_cache_flags() would just not
set BDRV_O_CACHE_WB, which can then be used exclusively by the lower
layers for their parsing (and bdrv_open_common would just set
bs->open_flags to always have BDRV_O_CACHE_WB).

Then patch 2/16 would change to having bdrv_set_enable_write_cache()
toggle BDRV_O_CACHE_WCE.

> 
>> Is there a scenario currently that has raw-posix opened directly as a
>> writethrough file, or were you more concerned with future use?
> 
> Not for raw-posix, but IIRC some other protocol is opened directly
> without a format on top.  rbd perhaps?  I'm concerned of having to work
> around what seems like a bug elsewhere, in multiple protocols.
> 
> Paolo
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]