Add a "manual cull" property to block jobs that forces them to linger
in the block job list (visible to QMP queries) until the user
explicitly dismisses them via QMP.
The cull command itself is implemented in the next commit, and the
feature is exposed to drive-backup and blockdev-backup in the
On 10/02/2017 07:56 PM, Eric Blake wrote:
> On 10/02/2017 04:27 PM, John Snow wrote:
>>
>>
>> On 09/13/2017 12:03 PM, Eric Blake wrote:
>>> Previously, the alloc command required that input parameters be
>>> sector-aligned and clamped to 32 bits, because the underlying
>>> bdrv_is_allocated used
For drive-backup and blockdev-backup, expose the manual-cull
property, having it default to false. There are no universal
creation parameters, so it must be added to each job type that
it makes sense for individually.
Signed-off-by: John Snow
---
blockdev.c | 10
For jobs that complete when a monitor isn't looking, there's no way to
tell what the job's final return code was. We need to allow jobs to
remain in the list until queried for reliable management.
This is an RFC; tests are on the way.
(Tested only manually via qmp-shell for now.)
John Snow (3):
For jobs that have finished (either completed or canceled), allow the
user to dismiss the job's status reports via block-job-cull.
Signed-off-by: John Snow
---
block/trace-events | 1 +
blockdev.c | 14 ++
qapi/block-core.json | 21
On Thu, Sep 28, 2017 at 10:12:34AM -0300, Eduardo Habkost wrote:
> On Thu, Sep 28, 2017 at 02:33:57AM -0600, Jan Beulich wrote:
> > >>> On 27.09.17 at 21:56, wrote:
> > > --- a/hw/xen/xen_pt.c
> > > +++ b/hw/xen/xen_pt.c
> > > @@ -964,6 +964,10 @@ static const TypeInfo
On 10/02/2017 04:27 PM, John Snow wrote:
>
>
> On 09/13/2017 12:03 PM, Eric Blake wrote:
>> Previously, the alloc command required that input parameters be
>> sector-aligned and clamped to 32 bits, because the underlying
>> bdrv_is_allocated used a 32-bit parameter and asserted aligned
>>
On 10/02/2017 03:24 PM, John Snow wrote:
>
>
> On 09/13/2017 12:03 PM, Eric Blake wrote:
>> Any device that has request_alignment greater than 512 should be
>> unable to report status at a finer granularity; it may also be
>> simpler for such devices to be guaranteed that the block layer
>> has