Il 18/10/2012 15:07, Kevin Wolf ha scritto:
>> > + s->synced = false;
>> > + if (read) {
>> > + return block_job_error_action(&s->common, s->common.bs,
>> > + s->on_source_error, true, error);
>> > + } else {
>> > + return block_job_error_action(&s->common, s->target,
>> > + s->on_target_error, false, error);
> Here we produce an event that reports an error on s->bs, i.e. on the
> source, even though the error was on the target.
More precisely, this is an event that reports an error on s->bs's job.
In principle there is no reason why asynchronous long-running operations
are tied to a block device (in fact migration fits the definition quite
well, with the only twist that the VM is stopped at the end), but that's
the API we're stuck with.
> This makes some sense
> today that the target doesn't have a name, but once it has, we would
> better use the target name here.
>
> Can we change this later on? If not, what's the way forward?
Yes, we can change it to one of these:
1) produce both a BLOCK_JOB_ERROR event on the source and a
BLOCK_IO_ERROR event on the target;
2) add a "device" argument to the BLOCK_JOB_ERROR and fill it.
I think I prefer the latter, but it can be discussed separately.
Paolo
