Re: [Qemu-devel] [PATCH 13/47] block: introduce block job error

[Paolo Bonzini <pbonzini@redhat.com>]

Il 01/08/2012 12:14, Kevin Wolf ha scritto:
>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> If we want to switch to named target block devices later, it would
> probably make sense to use the io_status of that block device rather
> than adding it to the job.
> 
> Maybe what results is a duplication that can be tolerated, though.

We are probably thinking of two opposite implementations.

You are thinking:

- errors in streaming, or in the mirroring source go to the block device

- errors in the mirroring target go to the block job

What I implemented is:

- errors in streaming, or in the mirroring source go to the block job

- errors in the mirroring target go to the target block device (which as
of this series could be inspected with query-block-jobs).


The reason is that an error in streaming or in the mirroring source does
not stop the VM.  A hypothetical management that polled for errors with
"info block" would see a mismatch between the error state ("failed") and
the VM RunState ("running").

So this is already ready for making the target block device visible.

The real question is: if I remove the possibility to inspect the (so far
anonymous) target device with query-block-jobs, how do you read the
status of the target device?...

Paolo

>> +    }
>> +    bdrv_emit_qmp_error_event(job->bs, QEVENT_BLOCK_JOB_ERROR, action, is_read);
>> +    if (action == BDRV_ACTION_STOP) {
>> +        block_job_pause(job);
>> +        if (bs == job->bs) {
>> +            block_job_iostatus_set_err(job, error);
>> +        } else {
>> +            bdrv_iostatus_set_err(bs, error);
>> +        }
> 
> However, so that everything just falls into place once we make the
> target block device visible, I'd make the bdrv_iostatus_set_err() call
> unconditional then.


Paolo