On Tue, 07/05 15:37, Kevin Wolf wrote:
> Am 17.06.2016 um 11:23 hat Kevin Wolf geschrieben:
> > Am 03.06.2016 um 10:48 hat Fam Zheng geschrieben:
> > > Respect the locking mode from CLI or QMP, and set the open flags
> > > accordingly.
> > >
> > > Signed-off-by: Fam Zheng
> > > Reviewed-by: Max R
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> With a bdrv_co_write_zeroes method on a target BDS zeroes will not be placed
The commit message doesn't match the code. A target BDS may have
bdrv_co_write_zeroes but still send zeroes across the wire (example: NBD
client that has my patch for using
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> There is no need to scan allocation tables if we have mark_all_dirty flag
> set. Just mark it all dirty.
>
> Signed-off-by: Denis V. Lunev
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> CC: Stefan Hajnoczi
> CC: Fam Zheng
> CC: Kevin Wolf
> CC: Ma
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> All nowadays .bdrv_co_write_zeroes callbacks could perfectly work even
Grammar:
All .bdrv_co_write_zeroes callbacks nowadays work perfectly even...
> with backing store attached. If future new callbacks will unable to do
s/will/would be/
> that -
On 07/04/2016 08:38 AM, Denis V. Lunev wrote:
> From: Evgeny Yakovlev
>
> Some guests (win2008 server for example) do a lot of unnecessary
> flushing when underlying media has not changed. This adds additional
> overhead on host when calling fsync/fdatasync.
>
> This change introduces a write ge
On 07/07/2016 06:11 AM, Kevin Wolf wrote:
> In order to remove the necessity to use BlockBackend names in the
> external API, we want to allow node-names everywhere. This converts
> block-commit to accept a node-name without lifting the restriction that
> we're operating at a root node.
>
> As lib
On 07/07/2016 06:11 AM, Kevin Wolf wrote:
> In order to remove the necessity to use BlockBackend names in the
> external API, we want to allow node-names everywhere. This converts
> block-stream to accept a node-name without lifting the restriction that
> we're operating at a root node.
>
> In cas
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> The code inside the helper will be extended in the next patch. mirror_run
> itself is overbloated at the moment.
>
> Signed-off-by: Denis V. Lunev
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> CC: Stefan Hajnoczi
> CC: Fam Zheng
> CC: Kevin Wolf
On 07/04/2016 10:53 AM, Paolo Bonzini wrote:
> On 04/07/2016 16:38, Denis V. Lunev wrote:
>> Changes from v4:
>> - Moved to write generation scheme instead of dirty flag
>> - Added retry setup to IDE PIO and FLUSH requests
>>
>> Changes from v3:
>> - Fixed a typo in commit message
>> - Rebased on
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> We keep here the sum of int fields. Thus this could easily overflow,
> especially when we will start sending big requests in next patches.
>
> Signed-off-by: Denis V. Lunev
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> CC: Stefan Hajnoczi
> CC: Fa
On 07/07/2016 03:35 AM, Denis V. Lunev wrote:
> Underlying HBitmap operates even with uint64_t. Thus this change is safe.
> This would be useful f.e. to mark entire bitmap dirty in one call.
>
> Signed-off-by: Denis V. Lunev
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> CC: Stefan Hajnoczi
> CC
On 06/22/2016 08:53 AM, Fam Zheng wrote:
> v2: Fix patch 1 #else branch, and "r" => "ret". [Kevin]
> Add Kevin's r-b line in patch 2.
>
> This is an independent tiny change extracted from the image locking series,
> which can be processed separately.
>
> Improved according to Kevin's sugges
On 07/06/2016 04:24 AM, Kevin Wolf wrote:
> Am 05.07.2016 um 22:50 hat John Snow geschrieben:
>>
>>
>> On 07/05/2016 11:49 AM, Daniel P. Berrange wrote:
>>> On Tue, Jul 05, 2016 at 11:24:04AM -0400, Colin Lord wrote:
This puts the bochs probe function into its own separate file as part of
On 07/05/2016 11:24 AM, Colin Lord wrote:
> This is the next version of this patch series. The first three patches
> in the series are mostly the same as they were last time, but with the
> issues mentioned in the reviews fixed. Most notably this means much less
> copy-paste happening in block.c.
On 07/07/2016 12:01 PM, Paolo Bonzini wrote:
>
>
> On 06/07/2016 18:09, John Snow wrote:
>> Recently the include files in hw/ide/ were moved to include/ without
>> anybody mentioning it to me, including internal.h.
>>
>> Why?
>
> Because hw/ide/internal.h is not so internal. In particular, it
On 06/07/2016 18:09, John Snow wrote:
> Recently the include files in hw/ide/ were moved to include/ without
> anybody mentioning it to me, including internal.h.
>
> Why?
Because hw/ide/internal.h is not so internal. In particular, it is
included by hw/ide/pci.h, which is included by hw/i386/p
On 05/07/2016 22:50, John Snow wrote:
> So, something like:
>
> block/drivers/bochs/
>
> bochs.c
> probe.c (or bochs-probe.c)
>
> and
>
> include/block/drivers/bochs/
>
> common.h (or internal.h)
>
>
> Any objections from the gallery?
I guess I'm missing why it is useful to modularize dri
On 07/07/2016 02:36 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 07/06/2016 04:24 AM, Kevin Wolf wrote:
>>> Am 05.07.2016 um 22:50 hat John Snow geschrieben:
On 07/05/2016 11:49 AM, Daniel P. Berrange wrote:
> On Tue, Jul 05, 2016 at 11:24:04AM -0400, Colin Lord w
On 07/07/2016 11:12 AM, Alberto Garcia wrote:
> On Thu 07 Jul 2016 02:48:17 PM CEST, Kevin Wolf wrote:
>>> Hi all,
>>>
>>> block jobs are currently identified by the name of the block backend
>>> of the BDS where the job was started.
>>>
>>> The problem with this is that you cannot have block job
On Thu 07 Jul 2016 02:48:17 PM CEST, Kevin Wolf wrote:
>> Hi all,
>>
>> block jobs are currently identified by the name of the block backend
>> of the BDS where the job was started.
>>
>> The problem with this is that you cannot have block jobs on nodes
>> where there is no such name.
>>
>> This
On 07/06/2016 11:59 AM, Max Reitz wrote:
> On 05.07.2016 17:24, Colin Lord wrote:
>> Modifies the bochs probe to return the format name as well as the
>> score as the final step of separating the probe function from the
>> driver. This keeps the probe completely independent of the driver,
>> making
Am 07.07.2016 um 16:39 hat Alberto Garcia geschrieben:
> On Thu 07 Jul 2016 04:17:21 PM CEST, Kevin Wolf wrote:
> >> > +static BlockDriverState *qmp_get_root_bs(const char *name, Error **errp)
> >> > +{
> >> > +BlockDriverState *bs;
> >> > +
> >> > +bs = bdrv_lookup_bs(name, name, errp);
>
On Thu 07 Jul 2016 04:17:21 PM CEST, Kevin Wolf wrote:
>> > +static BlockDriverState *qmp_get_root_bs(const char *name, Error **errp)
>> > +{
>> > +BlockDriverState *bs;
>> > +
>> > +bs = bdrv_lookup_bs(name, name, errp);
>> > +if (bs == NULL) {
>> > +return NULL;
>> > +}
>>
Am 07.07.2016 um 14:59 hat Alberto Garcia geschrieben:
> On Thu 07 Jul 2016 02:11:27 PM CEST, Kevin Wolf wrote:
> > In order to remove the necessity to use BlockBackend names in the
> > external API, we want to allow node-names everywhere. This converts
> > block-stream to accept a node-name withou
On Thu 07 Jul 2016 02:11:27 PM CEST, Kevin Wolf wrote:
> In order to remove the necessity to use BlockBackend names in the
> external API, we want to allow node-names everywhere. This converts
> block-stream to accept a node-name without lifting the restriction that
> we're operating at a root node
Am 05.07.2016 um 16:28 hat Alberto Garcia geschrieben:
> Hi all,
>
> block jobs are currently identified by the name of the block backend
> of the BDS where the job was started.
>
> The problem with this is that you cannot have block jobs on nodes
> where there is no such name.
>
> This series t
There is no reason why an NBD server couldn't be started for any node,
even if it's not on the top level. This converts nbd-server-add to
accept a node-name.
Note that there is a semantic difference between using a BlockBackend
name and the node name of its root: In the former case, the NBD server
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
drive-mirror to accept a node-name without lifting the restriction that
we're operating at a root node.
In case of an invalid device name, the command returns the G
On 07/07/2016 13:40, Peter Lieven wrote:
>>>
>> This can take a long time and the disks may not even be ever used. I
>> don't think it's a good idea.
>
> Sure, the target might stay unused, but why do you suspect its slow?
I don't suspect it's slow; it's just that it can be O(size of disk), an
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
drive-backup and the corresponding transaction action to accept a
node-name without lifting the restriction that we're operating at a root
node.
In case of an inval
The builtin NBD server uses its own BlockBackend now instead of reusing
the monitor/guest device one.
This means that it has its own writethrough setting now. The builtin
NBD server always uses writeback caching now regardless of whether the
guest device has WCE enabled. qemu-nbd respects the cach
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
blockdev-snapshot-delete-internal-sync to accept a node-name without
lifting the restriction that we're operating at a root node.
In case of an invalid device name,
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
blockdev-snapshot-internal-sync to accept a node-name without lifting
the restriction that we're operating at a root node.
In case of an invalid device name, the co
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
change-backing-file to accept a node-name without lifting the
restriction that we're operating at a root node.
In case of an invalid device name, the command return
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
blockdev-backup and the corresponding transaction action to accept a
node-name without lifting the restriction that we're operating at a root
node.
In case of an in
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
blockdev-mirror to accept a node-name without lifting the restriction
that we're operating at a root node.
Signed-off-by: Kevin Wolf
---
blockdev.c | 10
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
block-commit to accept a node-name without lifting the restriction that
we're operating at a root node.
As libvirt makes use of the DeviceNotFound error class, we m
As stated in the RFC I sent two weeks ago:
* Node level commands: We need to complete the conversion that makes
commands accept node names instead of BlockBackend names. In some places
we intentionally allow only BlockBackends because we don't know if the
command works in other p
In order to remove the necessity to use BlockBackend names in the
external API, we want to allow node-names everywhere. This converts
block-stream to accept a node-name without lifting the restriction that
we're operating at a root node.
In case of an invalid device name, the command returns the G
Am 30.06.2016 um 17:59 schrieb Paolo Bonzini:
On 30/06/2016 13:08, Peter Lieven wrote:
this fills up the allocationmap at iscsi_open. This helps
to reduce the number of get_block_status requests during runtime
significantly.
Signed-off-by: Peter Lieven
---
block/iscsi.c | 16 +++
Underlying HBitmap operates even with uint64_t. Thus this change is safe.
This would be useful f.e. to mark entire bitmap dirty in one call.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Kevin Wolf
CC: Max Reitz
CC: Jeff Cody
C
We should not take into account zero blocks for delay calculations.
They are not read and thus IO throttling is not required. In the
other case VM migration with 16 Tb QCOW2 disk with 4 Gb of data takes
days.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajn
This patchset contains patches dealing with known-to-be-zero areas in drive
mirror from [PATCH 0/9] major rework of drive-mirror patchset.
Changes from v1:
- only patches dealing with zeroes remains
- ported to current HEAD
- fixed issue with dirty-bitmap, int length is changed with int64
- fixed
The code inside the helper will be extended in the next patch. mirror_run
itself is overbloated at the moment.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Kevin Wolf
CC: Max Reitz
CC: Jeff Cody
CC: Eric Blake
---
block/mirro
We keep here the sum of int fields. Thus this could easily overflow,
especially when we will start sending big requests in next patches.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Kevin Wolf
CC: Max Reitz
CC: Jeff Cody
CC: E
All nowadays .bdrv_co_write_zeroes callbacks could perfectly work even
with backing store attached. If future new callbacks will unable to do
that - they have a chance to block this in bdrv_get_info().
Signed-off-by: Denis V. Lunev
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Kevin Wolf
CC: Max Reitz
With a bdrv_co_write_zeroes method on a target BDS zeroes will not be placed
into the wire. Thus the target could be very efficiently zeroed out. This
is should be done with the largest chunk possible.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC
There is no need to scan allocation tables if we have mark_all_dirty flag
set. Just mark it all dirty.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Kevin Wolf
CC: Max Reitz
CC: Jeff Cody
CC: Eric Blake
---
block/mirror.c | 8
On Wed, Jul 06, 2016 at 08:53:56AM -0600, Eric Blake wrote:
> On 07/06/2016 05:58 AM, Alberto Garcia wrote:
> > On Tue 05 Jul 2016 12:49:59 PM CEST, "Daniel P. Berrange"
> > wrote:
> >
> >> GLib >= 2.16 provides GChecksum API which is good enough
> >> for md5, sha1, sha256 and sha512. Use this a
On Thu, 07/07 10:42, Reda Sallahi wrote:
> Commit "cdeaf1f vmdk: add bdrv_co_write_zeroes" causes a regression on
> writes. It writes metadata after every write instead of doing it only once
> for each cluster.
>
> vmdk_pwritev() writes metadata whenever m_data is set as valid so this patch
> sets
On Tue 05 Jul 2016 06:43:13 PM CEST, "Daniel P. Berrange"
wrote:
> Call the existing qcrypto_hash_supports method from
> qcrypto_hash_bytesv instead of open-coding it again.
>
> Signed-off-by: Daniel P. Berrange
"PATCH 3/2" ? :-)
Reviewed-by: Alberto Garcia
Berto
On Tue 05 Jul 2016 12:49:59 PM CEST, "Daniel P. Berrange"
wrote:
> +cs = g_checksum_new(qcrypto_hash_alg_map[alg]);
> +
> +for (i = 0; i < niov; i++) {
> +g_checksum_update(cs, iov[i].iov_base, iov[i].iov_len);
> +}
Not too important, but you could do this after checking the
On Tue 05 Jul 2016 12:50:00 PM CEST, "Daniel P. Berrange"
wrote:
> The qcrypto hash APIs now guarantee that sha256 is available at
> compile time, so skipping registration is rarely needed. A check
> at time of open is kept to ensure good error reporting in the
> (unlikely) case sha256 is runtime
Commit "cdeaf1f vmdk: add bdrv_co_write_zeroes" causes a regression on
writes. It writes metadata after every write instead of doing it only once
for each cluster.
vmdk_pwritev() writes metadata whenever m_data is set as valid so this patch
sets m_data as valid only when we have a new cluster whic
Commit "cde6361 vmdk: add bdrv_co_write_zeroes" causes a regression on
writes. It writes metadata after every write instead of doing it only once
for each cluster.
vmdk_pwritev() writes metadata whenever m_data is set as valid so this patch
sets m_data as valid only when we have a new cluster whic
55 matches
Mail list logo
