On 05.11.2015 18:15, Paolo Bonzini wrote:
>
>
> On 04/11/2015 19:57, Max Reitz wrote:
>> BdrvAioNotifier *ban, *ban_next;
>>
>> - if (bs->job) {
>> - block_job_cancel_sync(bs->job);
>> - }
>> + assert(!bs->job);
>>
>
> Who does this when ejecting a BDS from a BB?
Nobody, which one can see as good or bad, depending on whether you liked
it or not (it's mostly bad, though).
So by removing this without replacement, block jobs continue to work on
their BDS (and own it) until they're completed.
One stance you can take is: Block jobs work on the BDS, so ejecting the
BDS from the BB should not have an impact anyway (the BB name is only
used as a shorthand for identifying the BDS).
Another stance you can take is: The user only sees that the block job
takes a device name, so it looks like it's working on the BB level and
should behave as such.
The first point becomes moot when one realizes that you can no longer
complete a running block job once its BDS has been detached from the BB,
since the block job commands take BB names.
However, let's just try it:
$ x86_64-softmmu/qemu-system-x86_64 -qmp stdio \
-drive if=none,file=test.qcow2,id=drive0,node-name=node0
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
"package": ""}, "capabilities": []}}
{'execute':'qmp_capabilities'}
{"return": {}}
{'execute':'drive-backup','arguments':{'device':'drive0','target':'out.qcow2','format':'qcow2','sync':'none'}}
Formatting 'out.qcow2', fmt=qcow2 size=67108864 backing_file=test.qcow2
backing_fmt=qcow2 encryption=off cluster_size=65536 lazy_refcounts=off
refcount_bits=16
{"return": {}}
{'execute':'eject','arguments':{'device':'drive0'}}
{"error": {"class": "GenericError", "desc": "Node 'drive0' is busy:
block device is in use by block job: backup"}}
So... Nobody does it, but apparently nobody has to because you cannot
eject (to be more specific: use blockdev-remove-medium) a BDS from a BB
while a block job is running on the BDS.
Max
signature.asc
Description: OpenPGP digital signature
