From: Jeff Cody <jcody@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, supriyak@linux.vnet.ibm.com, eblake@redhat.com,
qemu-devel@nongnu.org, stefanha@gmail.com
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 17:45:51 -0400 [thread overview]
Message-ID: <5052540F.5050501@redhat.com> (raw)
In-Reply-To: <50524246.5080800@redhat.com>
On 09/13/2012 04:29 PM, Paolo Bonzini wrote:
> Il 13/09/2012 21:44, Paolo Bonzini ha scritto:
>> Il 13/09/2012 21:04, Jeff Cody ha scritto:
>>>>> 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.
>>>
>>
>> Yeah, that would work.
>>
>> Alternatively, we can keep this patch and leave bdrv_open_common as is;
>> but then I would also prefer if raw-{posix,win32} took care of setting
>> BDRV_O_CACHE_WB in bs->open_flags, so that the flags are consistent.
>> This setting of BDRV_O_CACHE_WB can be extended later to other formats.
>
> Hmm, no, what was I thinking...
>
> But there is a very simple thing we can do:
>
> - patch 2 can be left as is
>
> - in patch 3 bdrv_reopen_queue, always add BDRV_O_CACHE_WB to
> bs_entry->state.flags
>
> - in patch 3 bdrv_reopen_commit, always leave BDRV_O_CACHE_WB aside:
>
> reopen_state->bs->open_flags =
> (bs->open_flags & BDRV_O_CACHE_WB) |
> (reopen_state->flags & ~BDRV_O_CACHE_WB);
>
> - this patch can be dropped completely.
>
Yes, I think that would work. The only thing I don't like is that
BDRV_O_CACHE_WB still remains a bit confusing when looking through the
code... bs->open_flags does not actually represent the open flags.
With what I proposed above, here are the steps needed:
- bdrv_parse_cache_flags() sets BDRV_O_CACHE_WCE instead of
BDRV_O_CACHE_WB
- BDRV_O_CACHE_WCE is used everywhere enable_write_cache was used
- bs->enable_write_cache is removed
- this patch is dropped
- bdrv_open_common() sets bs->open_flags to have BDRV_O_CACHE_WB enabled
by default.
- The only way BDRV_O_CACHE_WB would get cleared from bs->open_flags now
would be if someone explicitly cleared it during a bdrv_reopen().
While there are more changes this way, I think it cleans up the code a
bit. The advantage is that bs->open_flags actually reflects the open
flags that are currently in use. One disadvantage I see is that it
seems a bit odd to have BDRV_O_CACHE_WCE cleared and BDRV_O_CACHE_WB
set, until you think about them being intended for different layers.
Maybe that is part of the underlying problem - there is one open_flags
variable in the BDS, that has some flags intended for all layers in the
block stack, and some flags specific to a layer.
next prev parent reply other threads:[~2012-09-13 21:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 15:49 [Qemu-devel] [PATCH v2 00/16] block: bdrv_reopen() patches Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 01/16] block: correctly set the keep_read_only flag Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 02/16] block: make bdrv_set_enable_write_cache() modify open_flags Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 03/16] block: Framework for reopening files safely Jeff Cody
2012-09-13 16:20 ` Paolo Bonzini
2012-09-13 20:35 ` Paolo Bonzini
2012-09-13 20:51 ` Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 04/16] block: move aio initialization into a helper function Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 05/16] block: move open flag parsing in raw block drivers to helper functions Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers Jeff Cody
2012-09-13 16:12 ` Paolo Bonzini
2012-09-13 17:17 ` Jeff Cody
2012-09-13 18:56 ` Paolo Bonzini
2012-09-13 19:04 ` Jeff Cody
2012-09-13 19:44 ` Paolo Bonzini
2012-09-13 20:29 ` Paolo Bonzini
2012-09-13 21:45 ` Jeff Cody [this message]
2012-09-14 6:51 ` Paolo Bonzini
2012-09-14 7:54 ` Kevin Wolf
2012-09-14 7:27 ` Kevin Wolf
2012-09-14 7:50 ` Paolo Bonzini
2012-09-14 7:55 ` Kevin Wolf
2012-09-14 7:55 ` Paolo Bonzini
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 07/16] block: move allocating aligned_buf into a helper function in raw_posix.c Jeff Cody
2012-09-13 17:29 ` Eric Blake
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 08/16] block: raw-posix image file reopen Jeff Cody
2012-09-13 16:02 ` Paolo Bonzini
2012-09-13 16:57 ` Jeff Cody
2012-09-14 7:32 ` Kevin Wolf
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 09/16] block: raw " Jeff Cody
2012-09-13 16:05 ` Paolo Bonzini
2012-09-13 17:02 ` Jeff Cody
2012-09-13 18:53 ` Paolo Bonzini
2012-09-13 19:17 ` Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 10/16] block: qed " Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 11/16] block: qcow2 " Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 12/16] block: qcow " Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 13/16] block: vmdk " Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 14/16] block: raw-win32 driver reopen support Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 15/16] block: convert bdrv_commit() to use bdrv_reopen() Jeff Cody
2012-09-13 15:49 ` [Qemu-devel] [PATCH v2 16/16] block: remove keep_read_only flag from BlockDriverState struct Jeff Cody
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5052540F.5050501@redhat.com \
--to=jcody@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=supriyak@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).