On Mon, Oct 10, 2016 at 02:28:52PM -0500, Eric Blake wrote:
> On 10/10/2016 01:36 PM, John Snow wrote:
[...]
> > I'll be honest that I don't know; this is related to Replication which I
> > know reasonably little about overall. It got added in the 2.8 timeframe,
> > so the behavior it currently e
John Snow writes:
> On 10/05/2016 09:43 AM, Kevin Wolf 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 wa
On 10/10/2016 01:36 PM, John Snow wrote:
But if it cannot figure out which upper-layer disk the event is
associated with, it just drops the event. So I think that from the
libvirt perspective, you are okay if if you always report job events,
even for internal jobs. (Do we hav
On 10/10/2016 12:45 PM, Kashyap Chamarthy wrote:
On Wed, Oct 05, 2016 at 05:00:29PM -0400, John Snow wrote:
[Arbitrarily chiming here, and still catching up with the details of the
thread.]
On 10/05/2016 03:24 PM, Eric Blake wrote:
On 10/05/2016 01:49 PM, John Snow wrote:
[...]
Hmm, do
On Wed, Oct 05, 2016 at 05:00:29PM -0400, John Snow wrote:
[Arbitrarily chiming here, and still catching up with the details of the
thread.]
> On 10/05/2016 03:24 PM, Eric Blake wrote:
> > On 10/05/2016 01:49 PM, John Snow wrote:
[...]
> > > Hmm, do we want to make it so some jobs are invisibl
On 10/06/2016 02:16 PM, Eric Blake wrote:
On 10/06/2016 11:57 AM, John Snow wrote:
Mirrors "internal bitmaps," too.
I can rig it such that if a job has no ID, it will cease to show up via
query and no longer emit events.
Downside: Whether or not a device is busy or can accept another job
bec
On 10/06/2016 11:57 AM, John Snow wrote:
> Mirrors "internal bitmaps," too.
>
> I can rig it such that if a job has no ID, it will cease to show up via
> query and no longer emit events.
>
> Downside: Whether or not a device is busy or can accept another job
> becomes opaque to the management lay
On 10/06/2016 03:44 AM, Kevin Wolf wrote:
Am 05.10.2016 um 20:49 hat John Snow geschrieben:
On 10/05/2016 09:43 AM, Kevin Wolf wrote:
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
@@ -3136,10 +3111,10 @@ void qmp_block_commit(bool has_job_id, const char
*job_id, const char *device,
Am 05.10.2016 um 20:49 hat John Snow geschrieben:
> On 10/05/2016 09:43 AM, Kevin Wolf wrote:
> >Am 01.10.2016 um 00:00 hat John Snow geschrieben:
> >>@@ -3136,10 +3111,10 @@ void qmp_block_commit(bool has_job_id, const char
> >>*job_id, const char *device,
> >> goto out;
> >>
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 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 ++---
12 matches
Mail list logo