From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3KuQ-0001jE-Qv for qemu-devel@nongnu.org; Mon, 30 Nov 2015 04:38:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3KuP-0001wn-95 for qemu-devel@nongnu.org; Mon, 30 Nov 2015 04:38:10 -0500 Date: Mon, 30 Nov 2015 10:37:59 +0100 From: Kevin Wolf Message-ID: <20151130093759.GB4494@noname.str.redhat.com> References: <1448294400-476-1-git-send-email-kwolf@redhat.com> <1448294400-476-18-git-send-email-kwolf@redhat.com> <5658B5A1.3070106@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <5658B5A1.3070106@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 17/21] block: Move cache options into options QDict List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 27.11.2015 um 20:57 hat Max Reitz geschrieben: > On 23.11.2015 16:59, Kevin Wolf wrote: > > This adds the cache mode options to the QDict, so that they can be > > specified for child nodes (e.g. backing.cache.direct=3Doff). > >=20 > > The cache modes are not removed from the flags at this point; instead, > > options and flags are kept in sync. If the user specifies both flags and > > options, the options take precedence. > >=20 > > Child node inherit cache modes as options now, they don't use flags any > > more. > >=20 > > Note that this forbids specifying the cache mode for empty drives. It > > didn't make sense anyway to specify it there, because it didn't have any > > effect. blockdev_init() considers the cache options now bdrv_open() > > options and therefore doesn't create an empty drive any more but calls > > into bdrv_open(). This in turn will fail with no driver and filename > > specified. > >=20 > > Signed-off-by: Kevin Wolf > > --- > > block.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++--- > > blockdev.c | 52 ++++++++++---------------------- > > 2 files changed, 111 insertions(+), 41 deletions(-) > >=20 > > diff --git a/block.c b/block.c > > index eff0c19..397014a 100644 > > --- a/block.c > > +++ b/block.c >=20 > [...] >=20 > > @@ -1747,12 +1816,22 @@ static BlockReopenQueue *bdrv_reopen_queue_chil= d(BlockReopenQueue *bs_queue, > > /* > > * Precedence of options: > > * 1. Explicitly passed in options (highest) > > - * 2. TODO Set in flags (only for top level) > > + * 2. Set in flags (only for top level) > > * 3. Retained from explicitly set options of bs > > * 4. Inherited from parent node > > * 5. Retained from effective options of bs > > */ > > =20 > > + if (!parent_options) { > > + /* > > + * Any setting represented by flags is always updated. If the > > + * corresponding QDict option is set, it takes precedence. Oth= erwise > > + * the flag is translated into a QDict option. The old setting= of bs is > > + * not considered. > > + */ > > + update_options_from_flags(options, flags); > > + } > > + > > /* Old explicitly set values (don't overwrite by inherited value) = */ > > old_options =3D qdict_clone_shallow(bs->explicit_options); > > bdrv_join_options(bs, options, old_options); > > @@ -1923,6 +2002,19 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_= state, BlockReopenQueue *queue, > > goto error; > > } > > =20 > > + update_flags_from_options(&reopen_state->flags, opts); > > + > > + /* If a guest device is attached, it owns WCE */ > > + if (reopen_state->bs->blk && blk_get_attached_dev(reopen_state->bs= ->blk)) { > > + bool old_wce =3D bdrv_enable_write_cache(reopen_state->bs); > > + bool new_wce =3D (reopen_state->flags & BDRV_O_CACHE_WB); > > + if (old_wce !=3D new_wce) { > > + error_setg(errp, "Cannot change cache.writeback: Device at= tached"); > > + ret =3D -EINVAL; > > + goto error; > > + } > > + } > > + >=20 > Time to get back to my question regarding bdrv_set_enable_write_cache(): Alles kaputt. :-) > 1. bdrv_set_enable_write_cache() sets/unsets BDRV_O_CACHE_WB in > bs->open_flags so that it is preserved through a reopen. > 2. On reopen, bdrv_reopen_queue_child() calls > update_options_from_flags() unless @parent_options is set. If that > function is called, it will set the appropriate caching options in > @options as dictated by bdrv_set_enable_write_cache(). > 3. If @parent_options was NULL, the update_flags_from_options() call > here in bdrv_reopen_prepare() will set BDRV_O_CACHE_WB just as > dictated by bdrv_set_enable_write_cache() (unless overwritten). > That is what we want. > 4. If @parent_options was not NULL, the caching options in > bs->open_flags are completely overwritten, discarding everything that > had been set by bdrv_set_enable_write_cache(). That's not so good. >=20 > @parent_options is tested so that update_options_from_flags() is called > only for root BDSs. It is possible to call bdrv_set_enable_write_cache() > on non-root BDSs (e.g. commit_active_start() does it on the commit base > via mirror_start_job()), so I do think overriding the setting made by > bdrv_set_enable_write_cache() on reopen for any non-root BDSs is not > correct. I think you didn't interpret @parent_options correctly. It is NULL for the node that bdrv_reopen() is called for. It is non-NULL for (recursive) child nodes of that node that inherit options from it. Not sure if it matters for this case, though. In my opinion, what these block jobs are doing is insane. They should never touch the cache mode of a node as long as this cache mode can be shared with other users. It doesn't matter much with block jobs that can only work on a BDS that they just created, but with blockdev-backup I'd consider this a real bug. > Maybe bdrv_set_enable_write_cache() should set cache.writeback in > bs->explicit_options to on or off instead of using bs->open_flags. But > in that case, we can no longer use bdrv_set_enable_write_cache() in > bdrv_open_common(), because the cache setting there may be implicit. The _real_ thing would be moving cache.writeback to the BB. That's out of scope for this series, though. I don't like to enbable the guest to change bs->explicit_options, because that doesn't feel very explicit, but I might consider it if we find a use case where it's necessary in order to get the desired behaviour. In the light of the above, however, I'm inclined to think that it's an (accidental) bug mitigation feature rather than a bug. Kevin --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWXBj3AAoJEH8JsnLIjy/Wc9sP/iMjptw87/glXcljvaAozjfB D/QGOTJozt5RGJgwyb5X0f6o7qy+zXEDPaVGD72ZJBYDnpzQ1DFPjgDyvSQvVYMr 7yIUCbyO/EJ2H3Ex52Zi1OStvq1TLfxdtTz4YbtuwXmztMfM4sEfVye1/IKFcwtM 8aKhZtDkfIDjB0yRaalazf7CyaNdL2NVKGUBjGvzIaLVxCQwwdNxUVorJAWgkq57 gfO3CT+qCEYyQTudPLyeZtgMzdwD0hFR3yWormW5ZmXPbJNm1Os2PMOAe9t7N8Sj CVthF6HaIiZf3QDVProc3mw+6uwN8qw70QEWN9pPGXrv9gQFJt1g1A9lyuxFKlBT P0nDdJ+1ZyTTeEJxly0USRgJ3Qa4Otu/BKaOeoxhp8Um54oLpqLSyR7JsJgMLz1A 2dzejUIENF6Qdw6LfMxVhjhXr/S8Os3Rn81fFTBJu0BoMCSia9Ol7LVhsgI7/nBI JmyzPMHRjvS9hpGqUl8tec91zba7hN6T106UWXV8yj+yv/SjEdzW+Acxtpoa2qd1 1aj3McfN9an/rNKDtP2qKmdUc/1xlk992f9lFYKr7/h7J2u3rd1tUwtb9UsrlNb5 BFJPrEo2w9Q0q3rFhMoLgaMCPYKLAENLTvplI5JOg4gh724BCrz4HcrXMBO1T6Na /bmdH8z6V0G0ysksjsys =m9dj -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y--