On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote:
> The following functions fail if bs->drv is a filter and does not
> implement them:
>
> bdrv_probe_blocksizes
> bdrv_probe_geometry
> bdrv_truncate
> bdrv_has_zero_init
> bdrv_get_info
>
> Instead, the call should be passed to bs->file if it exi
On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote:
> This function is not used anywhere, so remove it.
>
> Signed-off-by: Manos Pitsidianakis
> ---
> block.c | 14 --
> block/raw-format.c| 6 --
> include/block/block.h | 1 -
> include/block/block_
Now that all callers are using byte-based interfaces, there's no
reason for our internal hbitmap to remain with sector-based
granularity. It also simplifies our internal scaling, since we
already know that hbitmap widens requests out to granularity
boundaries.
Signed-off-by: Eric Blake
---
v5:
Both callers already had bytes available, but were scaling to
sectors. Move the scaling to internal code. In the case of
bdrv_aligned_pwritev(), we are now passing the exact offset
rather than a rounded sector-aligned value, but that's okay
as long as dirty bitmap widens start/bytes to granularit
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
---
v5: no change
v4: new patch
---
block/qcow2-bitmap.c |
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
Signed-off-by: Eric Blake
---
v5: rebase to earlier changes
v2-v4: no change
---
block/mirror.c | 38 +++
Some of the callers were already scaling bytes to sectors; others
can be easily converted to pass byte offsets, all in our shift
towards a consistent byte interface everywhere. Making the change
will also make it easier to write the hold-out callers to use byte
rather than sectors for their iterat
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
---
v5: no change
v4: new patch
---
block/qcow2-bitmap.c |
This is new code, but it is easier to read if it makes passes over
the image using bytes rather than sectors (and will get easier in
the future when bdrv_get_block_status is converted to byte-based).
While at it, fix a bug in the computation of nb_sectors using MAX
rather than MIN and thus always
Half the callers were already scaling bytes to sectors; the other
half can eventually be simplified to use byte iteration. Both
callers were already using the result as a bool, so make that
explicit. Making the change also makes it easier for a future
dirty-bitmap patch to offload scaling over to
We are still using an internal hbitmap that tracks a size in sectors,
with the granularity scaled down accordingly, because it lets us
use a shortcut for our iterators which are currently sector-based.
But there's no reason we can't track the dirty bitmap size in bytes,
since it is (mostly) an inte
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Change the qcow2 bitmap
helper function sectors_covered_by_bitmap_cluster(), renaming it
to bytes_covered_by_bitmap_cluster() in the process.
Signed-off-by: Eric Blake
Reviewed-by: John Sn
Thanks to recent cleanups, all callers were scaling a return value
of sectors into bytes; do the scaling internally instead.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Juan Quintela
---
v4: no change
v3: no change, add R-b
v2: no change
---
block/dirty-bitmap.c | 4 ++--
b
Right now, the dirty-bitmap code exposes the fact that we use
a scale of sector granularity in the underlying hbitmap to anything
that wants to serialize a dirty bitmap. It's nicer to uniformly
expose bytes as our dirty-bitmap interface, matching the previous
change to bitmap size. The only calle
All callers to bdrv_dirty_iter_new() passed 0 for their initial
starting point, drop that parameter.
Most callers to bdrv_set_dirty_iter() were scaling a byte offset to
a sector number; the exception qcow2-bitmap will be converted later
to use byte rather than sector iteration. Move the scaling t
Thanks to recent cleanups, most callers were scaling a return value
of sectors into bytes (the exception, in qcow2-bitmap, will be
converted to byte-based iteration later - in particular, there will
be a few commits where we are temporarily relying on not-strict-C
right-shift of -1 still resulting
The only client of hbitmap_serialization_granularity() is dirty-bitmap's
bdrv_dirty_bitmap_serialization_align(). Keeping the two names consistent
is worthwhile, and the shorter name is more representative of what the
function returns (the required alignment to be used for start/count of
other ser
There are patches floating around to add NBD_CMD_BLOCK_STATUS,
but NBD wants to report status on byte granularity (even if the
reporting will probably be naturally aligned to sectors or even
much higher levels). I've therefore started the task of
converting our block status code to report at a byt
We had several functions that no one is currently using, and which
use sector-based interfaces. I'm trying to convert towards byte-based
interfaces, so it's easier to just drop the unused functions:
bdrv_dirty_bitmap_get_meta
bdrv_dirty_bitmap_get_meta_locked
bdrv_dirty_bitmap_reset_meta
bdrv_dir
When subdividing a bitmap serialization, the code in hbitmap.c
enforces that start/count parameters are aligned (except that
count can end early at end-of-bitmap). We exposed this required
alignment through bdrv_dirty_bitmap_serialization_align(), but
forgot to actually check that we comply with i
We've been documenting the value in bytes since its introduction
in commit b9a9b3a4 (v1.3), where it was actually reported in bytes.
Commit e4654d2 (v2.0) then removed things from block/qapi.c, in
preparation for a rewrite to a list of dirty sectors in the next
commit 21b5683 in block.c, but the n
On 07/12/2017 04:00 PM, John Snow wrote:
>
>
> On 07/03/2017 11:10 AM, Eric Blake wrote:
>> Now that all callers are using byte-based interfaces, there's no
>> reason for our internal hbitmap to remain with sector-based
>> granularity. It also simplifies our internal scaling, since we
>> already
On 07/03/2017 11:10 AM, Eric Blake wrote:
> Now that all callers are using byte-based interfaces, there's no
> reason for our internal hbitmap to remain with sector-based
> granularity. It also simplifies our internal scaling, since we
> already know that hbitmap widens requests out to granulari
On 07/03/2017 11:10 AM, Eric Blake wrote:
> Now that we have adjusted the majority of the calls this function
> makes to be byte-based, it is easier to read the code if it makes
> passes over the image using bytes rather than sectors.
>
> Signed-off-by: Eric Blake
>
Reviewed-by: John Snow
V
On 07/03/2017 11:10 AM, Eric Blake wrote:
> Now that we have adjusted the majority of the calls this function
> makes to be byte-based, it is easier to read the code if it makes
> passes over the image using bytes rather than sectors.
>
> Signed-off-by: Eric Blake
>
Reviewed-by: John Snow
V
On 07/03/2017 11:10 AM, Eric Blake wrote:
> Some of the callers were already scaling bytes to sectors; others
> can be easily converted to pass byte offsets, all in our shift
> towards a consistent byte interface everywhere. Making the change
> will also make it easier to write the hold-out call
On 07/12/2017 01:00 PM, Max Reitz wrote:
> On 2017-07-12 16:56, Kevin Wolf wrote:
>> Am 12.07.2017 um 16:42 hat Eric Blake geschrieben:
>>> On 05/17/2017 07:38 AM, Max Reitz wrote:
>>>
>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
>>>
>>> Or, rather, force
On Wed, Jul 12, 2017 at 8:00 PM Max Reitz wrote:
> On 2017-07-12 16:56, Kevin Wolf wrote:
> > Am 12.07.2017 um 16:42 hat Eric Blake geschrieben:
> >> On 05/17/2017 07:38 AM, Max Reitz wrote:
> >>
> >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
> >>
> >> Or,
On Tue, Jul 11, 2017 at 03:49:50PM +0100, Daniel P. Berrange wrote:
On Tue, Jul 11, 2017 at 04:44:46PM +0200, Markus Armbruster wrote:
Markus Armbruster writes:
> Manos Pitsidianakis writes:
>
>> Is there a specific reason this patch wasn't finished? If I'm not
>> wrong using non-scalar prope
On 2017-07-12 16:56, Kevin Wolf wrote:
> Am 12.07.2017 um 16:42 hat Eric Blake geschrieben:
>> On 05/17/2017 07:38 AM, Max Reitz wrote:
>>
>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
>>
>> Or, rather, force the open of a backing image if one was specified
>
On 2017-07-12 16:52, Kevin Wolf wrote:
> Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben:
>> This patch add shrinking of the image file for qcow2. As a result, this
>> allows
>> us to reduce the virtual image size and free up space on the disk without
>> copying the image. Image can be fragm
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> This test makes sure that all block devices show up on 'info block',
> with all of the expected information, in different configurations.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/186 | 147 ++
> tests/qemu-iotests/186.ou
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> This caused an assertion failure until recently because the BlockBackend
> would be detached on unplug, but was in fact never attached in the first
> place. Add a regression test.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/067 | 13 ++
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> If no drive=... option is passed (for an empty drive), we don't only
> lack the BlockBackend normally created by parse_drive(), but we also
> need to manually call blk_attach_dev().
>
> This fixes at least a segfault when unplugging such devices, the bug
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> If no drive=... option is passed (for an empty drive), we don't only
> lack the BlockBackend normally created by parse_drive(), but we also
> need to manually call blk_attach_dev().
>
> IDE does not support hot unplug, but if it did, qdev would take care
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> Instead of listing only monitor-owned BlockBackends in query-block, also
> add those anonymous BlockBackends that are owned by a qdev device and as
> such under the control of the user.
>
> This allows to use query-block to inspect BlockBackends for the
On Wed, Jul 12, 2017 at 05:15:01PM +0200, Kevin Wolf wrote:
Am 12.07.2017 um 09:41 hat Markus Armbruster geschrieben:
Eric Blake writes:
> On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote:
>> This function is not used anywhere, so remove it.
>>
>
> Might be interesting to figure out when it W
Am 12.07.2017 um 10:10 hat Manos Pitsidianakis geschrieben:
> On Wed, Jul 12, 2017 at 09:49:20AM +0200, Markus Armbruster wrote:
> >Manos Pitsidianakis writes:
> >
> >>This series makes implementing some of the bdrv_* callbacks easier for block
> >>filters by passing requests to bs->file if bs->dr
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> This patch replaces the blk_next() loop in query-block by a
> blk_all_next() one so that we also get access to BlockBackends that
> aren't owned by the monitor. For now, the next thing we do is check
> whether each BB has a name, so there is no semantical
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> block/block-backend.c | 2 +-
> include/sysemu/block-backend.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Eric Blake
(although the commit message could mention WHY it is useful to
30.06.2017 03:27, John Snow wrote:
On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote:
The function should collect statistics, about used/unused by top-level
format driver space (in its .file) and allocation status
(data/zero/discarded/after-eof) of corresponding areas in this .file.
S
Am 12.07.2017 um 09:41 hat Markus Armbruster geschrieben:
> Eric Blake writes:
>
> > On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote:
> >> This function is not used anywhere, so remove it.
> >>
> >
> > Might be interesting to figure out when it WAS last used.
>
> Yes. When I see "remove X be
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> With -blockdev/-device, users can indirectly create anonymous
> BlockBackends, in the state of which they are still interested. As a
Reads awkwardly. Maybe:
BlockBackends, although it is still of interest to learn the state of
such backends.
> prepara
Am 12.07.2017 um 16:42 hat Eric Blake geschrieben:
> On 05/17/2017 07:38 AM, Max Reitz wrote:
>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
>
> Or, rather, force the open of a backing image if one was specified
> for creation. Using a similar -u
On 07/12/2017 07:57 AM, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> block/block-backend.c | 3 +--
> include/sysemu/block-backend.h | 1 +
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben:
> This patch add shrinking of the image file for qcow2. As a result, this allows
> us to reduce the virtual image size and free up space on the disk without
> copying the image. Image can be fragmented and shrink is done by punching
> holes
>
Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben:
> Whenever l2/refcount table clusters are discarded from the file we can
> automatically drop unnecessary content of the cache tables. This reduces
> the chance of eviction useful cache data and eliminates inconsistent data
> in the cache with
On 05/17/2017 07:38 AM, Max Reitz wrote:
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
Or, rather, force the open of a backing image if one was specified
for creation. Using a similar -unsafe option as rebase, allow qemu-img
to ignore the b
On 07/12/2017 03:56 AM, Ala Hino wrote:
> Hi,
>
> We encountered a performance issue when creating a volume for a running VM
> and we'd like to share the info with you. The root cause of the issue is in
> our code but we found a workaround that relies on qemu-img create
> undocumented behavior.
>
On 2017-07-12 13:46, Pavel Butsykin wrote:
> This patch add shrinking of the image file for qcow2. As a result, this allows
> us to reduce the virtual image size and free up space on the disk without
> copying the image. Image can be fragmented and shrink is done by punching
> holes
> in the image
On 12/07/2017 03:07, Fam Zheng wrote:
> On Tue, 07/11 12:28, Paolo Bonzini wrote:
>> On 11/07/2017 12:05, Stefan Hajnoczi wrote:
>>> On Mon, Jul 10, 2017 at 05:08:56PM +0200, Paolo Bonzini wrote:
On 10/07/2017 17:07, Stefan Hajnoczi wrote:
> On Wed, Jul 05, 2017 at 09:36:32PM +0800, Fam Zh
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 2 +-
include/sysemu/block-backend.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/block-backend.c b/block/block-backend.c
index d60e53b..15072f8 100644
--- a/block/block-backend.c
+++ b/block/block-backen
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 3 +--
include/sysemu/block-backend.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/block-backend.c b/block/block-backend.c
index 0df3457..d60e53b 100644
--- a/block/block-backend.c
+++ b/block/block-back
If no drive=... option is passed (for an empty drive), we don't only
lack the BlockBackend normally created by parse_drive(), but we also
need to manually call blk_attach_dev().
IDE does not support hot unplug, but if it did, qdev would take care to
call the matching blk_detach_dev() on unplug.
T
If no drive=... option is passed (for an empty drive), we don't only
lack the BlockBackend normally created by parse_drive(), but we also
need to manually call blk_attach_dev().
This fixes at least a segfault when unplugging such devices, the bug
that they didn't show up in query-block, and probab
This caused an assertion failure until recently because the BlockBackend
would be detached on unplug, but was in fact never attached in the first
place. Add a regression test.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/067 | 13 +
tests/qemu-iotests/067.out | 39 +++
This test makes sure that all block devices show up on 'info block',
with all of the expected information, in different configurations.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/186 | 147 ++
tests/qemu-iotests/186.out | 489 +
t
Since 2.9 it is possible for a user to care only about nodes and qdev devices,
but not about BlockBackends, by defining with -blockdev and using their node
name in -device. Devices create an anonymous BlockBackend internally then.
One of the major problems in this setup is that such devices are no
Instead of listing only monitor-owned BlockBackends in query-block, also
add those anonymous BlockBackends that are owned by a qdev device and as
such under the control of the user.
This allows to use query-block to inspect BlockBackends for the modern
configuration syntax with -blockdev and -devi
With -blockdev/-device, users can indirectly create anonymous
BlockBackends, in the state of which they are still interested. As a
preparation for making such BBs visible in query-block, make sure that
they can be identified even without a name by adding the ID/QOM path of
their qdev device to Bloc
This patch replaces the blk_next() loop in query-block by a
blk_all_next() one so that we also get access to BlockBackends that
aren't owned by the monitor. For now, the next thing we do is check
whether each BB has a name, so there is no semantical difference.
Signed-off-by: Kevin Wolf
---
bloc
Signed-off-by: Pavel Butsykin
Reviewed-by: Max Reitz
---
tests/qemu-iotests/163 | 170 +
tests/qemu-iotests/163.out | 5 ++
tests/qemu-iotests/group | 1 +
3 files changed, 176 insertions(+)
create mode 100644 tests/qemu-iotests/163
create
Whenever l2/refcount table clusters are discarded from the file we can
automatically drop unnecessary content of the cache tables. This reduces
the chance of eviction useful cache data and eliminates inconsistent data
in the cache with the data in the file.
Signed-off-by: Pavel Butsykin
Reviewed-
The flag is additional precaution against data loss. Perhaps in the future the
operation shrink without this flag will be blocked for all formats, but for now
we need to maintain compatibility with raw.
Signed-off-by: Pavel Butsykin
Reviewed-by: Max Reitz
---
qemu-img-cmds.hx | 4 ++--
q
This patch add shrinking of the image file for qcow2. As a result, this allows
us to reduce the virtual image size and free up space on the disk without
copying the image. Image can be fragmented and shrink is done by punching holes
in the image file.
Signed-off-by: Pavel Butsykin
Reviewed-by: Ma
This patch add shrinking of the image file for qcow2. As a result, this allows
us to reduce the virtual image size and free up space on the disk without
copying the image. Image can be fragmented and shrink is done by punching holes
in the image file.
# ./qemu-img create -f qcow2 image.qcow2 4G
Fo
Hi,
We encountered a performance issue when creating a volume for a running VM
and we'd like to share the info with you. The root cause of the issue is in
our code but we found a workaround that relies on qemu-img create
undocumented behavior.
During our tests, we found that in order to create a
On Wed, Jul 12, 2017 at 10:14:48AM +0800, Fam Zheng wrote:
> On Mon, 07/10 15:55, Stefan Hajnoczi wrote:
> > On Wed, Jul 05, 2017 at 09:36:31PM +0800, Fam Zheng wrote:
> > > +static int nvme_co_prw(BlockDriverState *bs, uint64_t offset, uint64_t
> > > bytes,
> > > + QEMUIOVec
On Tue, Jul 11, 2017 at 11:48:02AM +0200, Paolo Bonzini wrote:
> On 11/07/2017 11:43, Stefan Hajnoczi wrote:
> >>>
> >>> 1. Must be called under BQL?
> >>> 2. Can I/O requests be in flight?
> >>> 3. Is it thread-safe?
> >>>
> >>> Otherwise it will be a nightmare to modify the code since these
> >>>
On Tue, Jul 11, 2017 at 07:37:48PM +0300, Manos Pitsidianakis wrote:
> bdrv_co_get_block_status_from_file() and
> bdrv_co_get_block_status_from_backing() set *file to bs->file and
> bs->backing respectively, so that bdrv_co_get_block_status() can recurse
> to them. Future block drivers won't have t
On Tue, Jul 11, 2017 at 07:37:47PM +0300, Manos Pitsidianakis wrote:
> Now that bdrv_truncate is passed to bs->file by default, remove the
> callback from block/blkdebug.c and set is_filter to true.
>
> Signed-off-by: Manos Pitsidianakis
> ---
> block/blkdebug.c | 7 +--
> 1 file changed, 1
On Tue, Jul 11, 2017 at 07:37:45PM +0300, Manos Pitsidianakis wrote:
> The following functions fail if bs->drv is a filter and does not
> implement them:
>
> bdrv_probe_blocksizes
> bdrv_probe_geometry
> bdrv_truncate
> bdrv_has_zero_init
> bdrv_get_info
>
> Instead, the call should be passed to
On Tue, Jul 11, 2017 at 07:37:46PM +0300, Manos Pitsidianakis wrote:
> This function is not used anywhere, so remove it.
>
> Signed-off-by: Manos Pitsidianakis
> ---
> block.c | 14 --
> block/raw-format.c| 6 --
> include/block/block.h | 1 -
> in
On Wed, Jul 12, 2017 at 10:33:37AM +0200, Kevin Wolf wrote:
Am 11.07.2017 um 20:50 hat Manos Pitsidianakis geschrieben:
On Tue, Jul 11, 2017 at 05:16:17PM +0200, Kevin Wolf wrote:
>Am 01.07.2017 um 17:39 hat Manos Pitsidianakis geschrieben:
>>bdrv_open_driver() is called in two places, bdrv_new_
Am 11.07.2017 um 20:50 hat Manos Pitsidianakis geschrieben:
> On Tue, Jul 11, 2017 at 05:16:17PM +0200, Kevin Wolf wrote:
> >Am 01.07.2017 um 17:39 hat Manos Pitsidianakis geschrieben:
> >>bdrv_open_driver() is called in two places, bdrv_new_open_driver() and
> >>bdrv_open_common(). In the latter,
On Wed, Jul 12, 2017 at 09:49:20AM +0200, Markus Armbruster wrote:
Manos Pitsidianakis writes:
This series makes implementing some of the bdrv_* callbacks easier for block
filters by passing requests to bs->file if bs->drv doesn't implement it instead
of failing, and adding default bdrv_co_get
Manos Pitsidianakis writes:
> This series makes implementing some of the bdrv_* callbacks easier for block
> filters by passing requests to bs->file if bs->drv doesn't implement it
> instead
> of failing, and adding default bdrv_co_get_block_status() implementations.
>
> This is based against Ke
Eric Blake writes:
> On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote:
>> This function is not used anywhere, so remove it.
>>
>
> Might be interesting to figure out when it WAS last used.
Yes. When I see "remove X because it's unused" during patch review, I
immediately ask "why is it unused
78 matches
Mail list logo
