On Thu, 24 May 2012 15:41:29 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> * block-stream: I would still like to add on_error to the existing > block-stream command, if only to ease unit testing. Concerns about the > stability of the API can be handled by adding introspection (exporting > the schema), which is not hard to do. The new option is an enum with > the following possible values: > > 'report': The behavior is the same as in 1.1. An I/O error will > complete the job immediately with an error code. > > 'ignore': An I/O error, respectively during a read or a write, will be > ignored. For streaming, the job will complete with an error and the > backing file will be left in place. For mirroring, the sector will be > marked again as dirty and re-examined later. > > 'stop': The job will be paused, and the job iostatus (which can be > examined with query-block-jobs) is updated. > > 'enospc': Behaves as 'stop' for ENOSPC errors, 'report' for others. > > In all cases, even for 'report', the I/O error is reported as a QMP > event BLOCK_JOB_ERROR, with the same arguments as BLOCK_IO_ERROR. > > After cancelling a job, the job implementation MAY choose to treat stop > and enospc values as report, i.e. complete the job immediately with an > error code, as long as block_job_is_cancelled(job) returns true when the > completion callback is called. > > Open problem: There could be unrecoverable errors in which the job > will always fail as if rerror/werror were set to report (example: > error while switching backing files). Does it make sense to fire an > event before the point in time where such errors can happen? You mean, you fire the event before the point the error can happen but the operation keeps running if it doesn't fail? If that's the case, I think that the returned error is enough for the mngt app to decide what to do. > * block-job-pause: A new QMP command. Takes a block device (drive), > pauses an active background block operation on that device. This > command returns immediately after marking the active background block > operation for pausing. It is an error to call this command if no > operation is in progress. The operation will pause as soon as possible > (it won't pause if the job is being cancelled). No event is emitted > when the operation is actually paused. Cancelling a paused job > automatically resumes it. Is pausing guaranteed to succeed?
