From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] [PATCH v5 0/6] block: Drop BDS.filename
Date: Mon, 19 Oct 2015 20:49:00 +0200 [thread overview]
Message-ID: <1445280546-26226-1-git-send-email-mreitz@redhat.com> (raw)
*** This series is based on v7 of my ***
*** "blockdev: BlockBackend and media" series ***
The BDS filename field is generally only used when opening disk images
or emitting error or warning messages, the only exception to this rule
is the map command of qemu-img. However, using exact_filename there
instead should not be a problem. Therefore, we can drop the filename
field from the BlockDriverState and use a function instead which builds
the filename from scratch when called.
This is slower than reading a static char array but the problem of that
static array is that it may become obsolete due to changes in any
BlockDriverState or in the BDS graph. Using a function which rebuilds
the filename every time it is called resolves this problem.
The disadvantage of worse performance is negligible, on the other hand.
After patch 2 of this series, which replaces some queries of
BDS.filename by reads from somewhere else (mostly BDS.exact_filename),
the filename field is only used when a disk image is opened or some
message should be emitted, both of which cases do not suffer from the
performance hit.
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg07025.html
gives an example of how to achieve an outdated filename, so we do need
this series. We can technically fix it differently (by appropriately
invoking bdrv_refresh_filename()), but that is pretty difficult™. I find
this series simpler and it it's something we wanted to do anyway.
Regarding the fear that this might change current behavior, especially
for libvirt which used filenames to identify nodes in the BDS graph:
Since bdrv_open() already calls bdrv_refresh_filename() today, and
apparently everything works fine, this series will most likely not break
anything. The only thing that will change is if the BDS graph is
dynamically reconfigured at runtime, and in that case it's most likely a
bug fix. Also, I don't think libvirt supports such cases already.
tl;dr: This series is a bug fix and I don't think it'll break legacy
management applications relying on the filename to identify a BDS; as
long as they are not trying to continue that practice with more advanced
configurations (e.g. with Quorum).
v5: (Rebased and addressed Eric's comments)
- Patch 1: Do not pstrcpy() into a caller-supplied buffer, but
g_strdup() instead [Eric]
- Patch 2: Rebase conflicts
- Patch 3: Drop bdrv_filename_alloc(), instead bdrv_filename() will
allocate a buffer if NULL is specified
- Patch 4: Use bdrv_filename() instead of bdrv_filename_alloc()
- Patch 5:
- Rebase conflicts
- Use bdrv_filename() instead of bdrv_filename_alloc()
git-backport-diff against v4:
Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
001/6:[0029] [FC] 'block: Change bdrv_get_encrypted_filename()'
002/6:[0004] [FC] 'block: Avoid BlockDriverState.filename'
003/6:[0040] [FC] 'block: Add bdrv_filename()'
004/6:[0002] [FC] 'qemu-img: Use bdrv_filename() for map'
005/6:[0093] [FC] 'block: Drop BlockDriverState.filename'
006/6:[----] [--] 'iotests: Test changed Quorum filename'
Max Reitz (6):
block: Change bdrv_get_encrypted_filename()
block: Avoid BlockDriverState.filename
block: Add bdrv_filename()
qemu-img: Use bdrv_filename() for map
block: Drop BlockDriverState.filename
iotests: Test changed Quorum filename
block.c | 105 +++++++++++++++++++++++++++++++++-------------
block/commit.c | 4 +-
block/gluster.c | 2 +-
block/mirror.c | 16 +++++--
block/qapi.c | 4 +-
block/raw-posix.c | 8 ++--
block/raw-win32.c | 4 +-
block/raw_bsd.c | 4 +-
block/vhdx-log.c | 5 ++-
block/vmdk.c | 22 +++++++---
block/vpc.c | 7 +++-
blockdev.c | 25 ++++++++---
include/block/block.h | 3 +-
include/block/block_int.h | 1 -
monitor.c | 5 ++-
qemu-img.c | 14 ++++++-
tests/qemu-iotests/041 | 17 ++++++--
17 files changed, 179 insertions(+), 67 deletions(-)
--
2.6.1
next reply other threads:[~2015-10-19 18:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 18:49 Max Reitz [this message]
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 1/6] block: Change bdrv_get_encrypted_filename() Max Reitz
2015-10-19 20:15 ` Eric Blake
2015-10-26 18:20 ` Kevin Wolf
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 2/6] block: Avoid BlockDriverState.filename Max Reitz
2015-10-19 20:35 ` Eric Blake
2015-10-26 16:51 ` Kevin Wolf
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 3/6] block: Add bdrv_filename() Max Reitz
2015-10-19 20:52 ` Eric Blake
2015-10-26 18:20 ` Kevin Wolf
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 4/6] qemu-img: Use bdrv_filename() for map Max Reitz
2015-10-19 21:02 ` Eric Blake
2015-10-26 18:21 ` Kevin Wolf
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 5/6] block: Drop BlockDriverState.filename Max Reitz
2015-10-19 21:11 ` Eric Blake
2015-10-27 9:39 ` Kevin Wolf
2015-10-19 18:49 ` [Qemu-devel] [PATCH v5 6/6] iotests: Test changed Quorum filename Max Reitz
2015-10-19 21:13 ` Eric Blake
2015-10-27 9:41 ` Kevin Wolf
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=1445280546-26226-1-git-send-email-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).