On 10/05/2016 03:24 PM, Eric Blake wrote:
On 10/05/2016 01:49 PM, John Snow wrote:
Here we have an additional caller in block/replication.c and qemu-img,
so the parameters must stay. For qemu-img, nothing changes. For
replication, the block job events are added as a side effect.
Not sure if
On 10/05/2016 01:49 PM, John Snow wrote:
>> Here we have an additional caller in block/replication.c and qemu-img,
>> so the parameters must stay. For qemu-img, nothing changes. For
>> replication, the block job events are added as a side effect.
>>
>> Not sure if we want to emit such events for a
On 10/05/2016 01:01 PM, Max Reitz wrote:
>> +static int blk_do_attach_dev(BlockBackend *blk, void *dev)
>> + */
>> +int blk_attach_dev(BlockBackend *blk, DeviceState *dev)
>> +{
>> +return blk_do_attach_dev(blk, dev);
>> +void blk_attach_dev_legacy(BlockBackend *blk, void *dev)
>> {
>>
On 10/05/2016 09:43 AM, Kevin Wolf wrote:
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
There's no reason to leave this to blockdev; we can do it in blockjobs
directly and get rid of an extra callback for most users.
Signed-off-by: John Snow
---
blockdev.c | 37 ++---
On 05.10.2016 11:26, Kevin Wolf wrote:
> The event currently only contains the BlockBackend name. However, with
> anonymous BlockBackends, this is always the empty string. Add the qdev
> ID (or if none was given, the QOM path) so that the user can still see
> which device caused the event.
>
> Eve
On 05.10.2016 11:26, Kevin Wolf wrote:
> Almost all block devices are qdevified by now. This allows us to go back
> from the BlockBackend to the DeviceState. xen_disk is the last device
> that is missing. We'll remember in the BlockBackend if a xen_disk is
> attached and can then disable any featur
On 05.10.2016 11:26, Kevin Wolf wrote:
> The event currently only contains the BlockBackend name. However, with
> anonymous BlockBackends, this is always the empty string. Add the node
> name so that the user can still see which block device caused the event.
>
> Signed-off-by: Kevin Wolf
> ---
>
On 05.10.2016 18:35, Paolo Bonzini wrote:
> In FIFO mode there are no parallel reads, hence there is no need to
> allocate separate buffers and clone the iovecs.
>
> The two cases of quorum_aio_cb are now even more different, and
> most of quorum_aio_finalize is only needed in one of them, so spli
On 05.10.2016 18:35, Paolo Bonzini wrote:
> This simplifies a bit the code by using the usual C "inclusive start,
> exclusive end" pattern for ranges.
>
> Signed-off-by: Paolo Bonzini
> ---
> block/quorum.c | 30 +-
> 1 file changed, 13 insertions(+), 17 deletions(-)
Please disregard this, I'll send it soon as part of the correct series.
Paolo
On 05/10/2016 18:47, Paolo Bonzini wrote:
> bdrv_requests_pending is checking children to also wait until internal
> requests (such as metadata writes) have completed. However, checking
> children is in general overkil
bdrv_requests_pending is checking children to also wait until internal
requests (such as metadata writes) have completed. However, checking
children is in general overkill. Children requests can be of two kinds:
- requests caused by an operation on bs, e.g. a bdrv_aio_write to bs
causing a write
This is required to decouple block jobs from running in an
AioContext. With multiqueue block devices, a BlockDriverState
does not really belong to a single AioContext.
The solution is to first wait until all I/O operations are
complete; then loop in the main thread for the block job to
complete e
In FIFO mode there are no parallel reads, hence there is no need to
allocate separate buffers and clone the iovecs.
The two cases of quorum_aio_cb are now even more different, and
most of quorum_aio_finalize is only needed in one of them, so split
them in separate functions.
Signed-off-by: Paolo
This simplifies a bit the code by using the usual C "inclusive start,
exclusive end" pattern for ranges.
Signed-off-by: Paolo Bonzini
---
block/quorum.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/block/quorum.c b/block/quorum.c
index 9cf8
A couple patches I had lying in the huge multiqueue series but are
not really related. So let's flush 'em...
Paolo Bonzini (2):
quorum: change child_iter to children_read
quorum: do not allocate multiple iovecs for FIFO strategy
block/quorum.c | 93 --
On 05.10.2016 00:52, John Snow wrote:
> From: Fam Zheng
>
> Signed-off-by: Fam Zheng
> [Fixed minor constant issue. --js]
> Signed-off-by: John Snow
>
> Signed-off-by: John Snow
> ---
> tests/test-hbitmap.c | 155
> +++
> 1 file changed, 155 i
On 10/05/2016 11:03 AM, Kevin Wolf wrote:
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
Wrong function names in documentation.
Signed-off-by: John Snow
---
include/block/blockjob_int.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/block/blockjob_int.h
On 10/05/2016 10:17 AM, Kevin Wolf wrote:
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
To make it a little more obvious which functions are intended to be
public interface and which are intended to be for use only by jobs
themselves, split the interface into "public" and "private" files.
On 05.10.2016 17:19, Alberto Garcia wrote:
> On Wed 05 Oct 2016 05:13:39 PM CEST, Max Reitz wrote:
>
> At least giving users a way to skip the math would be an
> improvement. Would you be okay with an explicitly-set option like
> l2_cache_size=auto or =max that optimizes for performan
Am 05.10.2016 um 17:13 hat Max Reitz geschrieben:
> On 05.10.2016 16:57, Alberto Garcia wrote:
> > On Tue 04 Oct 2016 05:51:26 PM CEST, Max Reitz wrote:
> >
> >>> At least giving users a way to skip the math would be an improvement.
> >>> Would you be okay with an explicitly-set option like
> >>>
On Wed 05 Oct 2016 05:13:39 PM CEST, Max Reitz wrote:
At least giving users a way to skip the math would be an
improvement. Would you be okay with an explicitly-set option like
l2_cache_size=auto or =max that optimizes for performance at the
expense of memory?
>>>
>> Frank Myh
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> Instead of automatically starting jobs at creation time via backup_start
> et al, we'd like to return a job object pointer that can be started
> manually at later point in time.
>
> For now, add the block_job_start mechanism and start the jobs
>
On 05.10.2016 16:57, Alberto Garcia wrote:
> On Tue 04 Oct 2016 05:51:26 PM CEST, Max Reitz wrote:
>
>>> At least giving users a way to skip the math would be an improvement.
>>> Would you be okay with an explicitly-set option like
>>> l2_cache_size=auto or =max that optimizes for performance at t
On Tue 04 Oct 2016 05:51:26 PM CEST, Max Reitz wrote:
>> At least giving users a way to skip the math would be an improvement.
>> Would you be okay with an explicitly-set option like
>> l2_cache_size=auto or =max that optimizes for performance at the
>> expense of memory?
>
> That (cache-size=max)
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> Wrong function names in documentation.
>
> Signed-off-by: John Snow
> ---
> include/block/blockjob_int.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/block/blockjob_int.h b/include/block/blockjob_int.h
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> There are a few places where we're fishing it out for ourselves.
> Let's not do that and instead use the helper.
>
> Signed-off-by: John Snow
That change makes a difference when the block job is running its
completion part after block_job_defer
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> To make it a little more obvious which functions are intended to be
> public interface and which are intended to be for use only by jobs
> themselves, split the interface into "public" and "private" files.
>
> Convert blockjobs (e.g. block/backup
On Tue, Oct 04, 2016 at 10:49:43AM +0200, Paolo Bonzini wrote:
> Register the notifier using the specific API for block devices.
>
> Signed-off-by: Paolo Bonzini
> ---
> block/write-threshold.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Stefan Hajnoczi
signature.a
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> There's no reason to leave this to blockdev; we can do it in blockjobs
> directly and get rid of an extra callback for most users.
>
> Signed-off-by: John Snow
> ---
> blockdev.c | 37 ++---
> blockjob.c | 16 +++
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> From: Vladimir Sementsov-Ogievskiy
>
> Though it is not intended to be reached through normal circumstances,
> if we do not gracefully deconstruct the transaction QLIST, we may wind
> up with stale pointers in the list.
>
> The rest of this ser
On 10/05/2016 05:57 AM, Denis V. Lunev wrote:
> When using a nbd block device, the info about necessity of prior disk
> zeroing could significantly improve the speed of certain operations
> (e.g. backups).
>
> This patch also will allow to preserve QCOW2 images during migration.
'allow to' is not
On 10/05/2016 04:54 AM, Thomas Huth wrote:
> The output string QEMU with "--version" is very long, it does
> not fit into a normal line of a terminal window anymore. By
> putting the copyright information on a separate line instead,
> the output looks much nicer.
>
> Signed-off-by: Thomas Huth
>
On Wed, Oct 05, 2016 at 10:12:57AM +0200, Kevin Wolf wrote:
> Am 04.10.2016 um 18:02 hat Stefan Hajnoczi geschrieben:
> > On Tue, Oct 04, 2016 at 01:55:30PM +0200, Kevin Wolf wrote:
> > > Am 04.10.2016 um 12:41 hat Denis V. Lunev geschrieben:
> > > > On 10/04/2016 12:34 PM, Kevin Wolf wrote:
> > >
Am 05.10.2016 um 12:57 hat Denis V. Lunev geschrieben:
> When using a nbd block device, the info about necessity of prior disk
> zeroing could significantly improve the speed of certain operations
> (e.g. backups).
>
> This patch also will allow to preserve QCOW2 images during migration.
> Managem
Am 05.10.2016 um 11:54 hat Thomas Huth geschrieben:
> The output string QEMU with "--version" is very long, it does
> not fit into a normal line of a terminal window anymore. By
> putting the copyright information on a separate line instead,
> the output looks much nicer.
>
> Signed-off-by: Thomas
When using a nbd block device, the info about necessity of prior disk
zeroing could significantly improve the speed of certain operations
(e.g. backups).
This patch also will allow to preserve QCOW2 images during migration.
Management software now may specify zero-init option and thus abscent
area
On 10/05/2016 12:55 PM, Paolo Bonzini wrote:
>
> On 05/10/2016 11:33, Denis V. Lunev wrote:
>> When using a nbd block device, the info about necessity of prior disk
>> zeroing could significantly improve the speed of certain operations
>> (e.g. backups).
>>
>> This patch also will allow to preserve
I reviewed this patch before noticing that the overall idea is not what
Kevin suggested, so I'm sending it out anyway. Further comments from
Kevin and Max might come since I am not familiar with the current
conventions on parsing block device options.
On 05/10/2016 11:33, Denis V. Lunev wrote:
>
On 05/10/2016 11:33, Denis V. Lunev wrote:
> When using a nbd block device, the info about necessity of prior disk
> zeroing could significantly improve the speed of certain operations
> (e.g. backups).
>
> This patch also will allow to preserve QCOW2 images during migration.
> Management softwa
The output string QEMU with "--version" is very long, it does
not fit into a normal line of a terminal window anymore. By
putting the copyright information on a separate line instead,
the output looks much nicer.
Signed-off-by: Thomas Huth
---
Note: I'm not sure whether there is a technical or l
Am 04.10.2016 um 10:49 hat Paolo Bonzini geschrieben:
> Register the notifier using the specific API for block devices.
>
> Signed-off-by: Paolo Bonzini
Thanks, applied to the block branch.
Kevin
From: Denis Plotnikov
When using a nbd block device, the info about necessity of prior disk
zeroing could significantly improve the speed of certain operations
(e.g. backups).
This patch also will allow to preserve QCOW2 images during migration.
Management software now may specify zero-init opti
When using a nbd block device, the info about necessity of prior disk
zeroing could significantly improve the speed of certain operations
(e.g. backups).
This patch also will allow to preserve QCOW2 images during migration.
Management software now may specify zero-init option and thus abscent
area
From: Denis Plotnikov
This is a preparatory commit to make code more generic. We are going to
add more options in the next patch.
Signed-off-by: Denis Plotnikov
Signed-off-by: Denis V. Lunev
CC: Paolo Bonzini
CC: Kevin Wolf
CC: Max Reitz
---
block/nbd.c | 143 ++
The event currently only contains the BlockBackend name. However, with
anonymous BlockBackends, this is always the empty string. Add the qdev
ID (or if none was given, the QOM path) so that the user can still see
which device caused the event.
Event generation has to be moved from bdrv_eject() to
Almost all block devices are qdevified by now. This allows us to go back
from the BlockBackend to the DeviceState. xen_disk is the last device
that is missing. We'll remember in the BlockBackend if a xen_disk is
attached and can then disable any features that require going from a BB
to the DeviceSt
The event currently only contains the BlockBackend name. However, with
anonymous BlockBackends, this is always the empty string. Add the node
name so that the user can still see which block device caused the event.
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 5 +++--
docs/qmp-events.tx
We have two QMP events that include only a BlockBackend name and that are
therefore useless with anonymous BBs. This series adds a node-name/qdev ID to
them.
Kevin Wolf (3):
block: Add node name to BLOCK_IO_ERROR event
block-backend: Remember if attached device is non-qdev
block: Add qdev ID
Am 04.10.2016 um 18:02 hat Stefan Hajnoczi geschrieben:
> On Tue, Oct 04, 2016 at 01:55:30PM +0200, Kevin Wolf wrote:
> > Am 04.10.2016 um 12:41 hat Denis V. Lunev geschrieben:
> > > On 10/04/2016 12:34 PM, Kevin Wolf wrote:
> > > > Am 04.10.2016 um 11:23 hat Stefan Hajnoczi geschrieben:
> > > >> O
49 matches
Mail list logo