Message ID | 20180223235142.21501-17-jsnow@redhat.com |
---|---|
State | New |
Headers | show |
Series | blockjobs: add explicit job management | expand |
On 02/23/2018 05:51 PM, John Snow wrote: > For jobs that are stuck waiting on others in a transaction, it would > be nice to know that they are no longer "running" in that sense, but > instead are waiting on other jobs in the transaction. > > Jobs that are "waiting" in this sense cannot be meaningfully altered > any longer as they have left their running loop. The only meaningful > user verb for jobs in this state is "cancel," which will cancel the > whole transaction, too. > > Transitions: > Running -> Waiting: Normal transition. > Ready -> Waiting: Normal transition. > Waiting -> Aborting: Transactional cancellation. > Waiting -> Concluded: Normal transition. > > Removed Transitions: > Running -> Concluded: Jobs must go to WAITING first. > Ready -> Concluded: Jobs must go to WAITING fisrt. s/fisrt/first/ > +++ b/blockjob.c > @@ -3934,6 +3938,29 @@ > 'offset': 'int', > 'speed' : 'int' } } > > +## > +# @BLOCK_JOB_WAITING: > +# > +# Emitted when a block job that is part of a transction has stopped work and is s/transction/transaction/ > +# waiting for other jobs in the transaction to reach the same state. Is this event emitted only for 'new-style' transactions (old drivers will never see it, because they don't request new style), or always (old drivers will see, but presumably ignore, it)?
On 02/27/2018 03:00 PM, Eric Blake wrote: > On 02/23/2018 05:51 PM, John Snow wrote: >> For jobs that are stuck waiting on others in a transaction, it would >> be nice to know that they are no longer "running" in that sense, but >> instead are waiting on other jobs in the transaction. >> >> Jobs that are "waiting" in this sense cannot be meaningfully altered >> any longer as they have left their running loop. The only meaningful >> user verb for jobs in this state is "cancel," which will cancel the >> whole transaction, too. >> >> Transitions: >> Running -> Waiting: Normal transition. >> Ready -> Waiting: Normal transition. >> Waiting -> Aborting: Transactional cancellation. >> Waiting -> Concluded: Normal transition. >> >> Removed Transitions: >> Running -> Concluded: Jobs must go to WAITING first. >> Ready -> Concluded: Jobs must go to WAITING fisrt. > > s/fisrt/first/ > >> +++ b/blockjob.c > >> @@ -3934,6 +3938,29 @@ >> 'offset': 'int', >> 'speed' : 'int' } } >> +## >> +# @BLOCK_JOB_WAITING: >> +# >> +# Emitted when a block job that is part of a transction has stopped >> work and is > > s/transction/transaction/ > >> +# waiting for other jobs in the transaction to reach the same state. > > Is this event emitted only for 'new-style' transactions (old drivers > will never see it, because they don't request new style), or always (old > drivers will see, but presumably ignore, it)? > ...! Actually, I meant to remove the WAITING *event* entirely, this is a mistake. It's purely an informational state that clients likely cannot make any real use of, because regardless of old or new style, jobs will transition automatically to "PENDING." That said, old or new, the state is visible from query-block-jobs. --js
Am 27.02.2018 um 21:50 hat John Snow geschrieben: > > > On 02/27/2018 03:00 PM, Eric Blake wrote: > > On 02/23/2018 05:51 PM, John Snow wrote: > >> For jobs that are stuck waiting on others in a transaction, it would > >> be nice to know that they are no longer "running" in that sense, but > >> instead are waiting on other jobs in the transaction. > >> > >> Jobs that are "waiting" in this sense cannot be meaningfully altered > >> any longer as they have left their running loop. The only meaningful > >> user verb for jobs in this state is "cancel," which will cancel the > >> whole transaction, too. > >> > >> Transitions: > >> Running -> Waiting: Normal transition. > >> Ready -> Waiting: Normal transition. > >> Waiting -> Aborting: Transactional cancellation. > >> Waiting -> Concluded: Normal transition. > >> > >> Removed Transitions: > >> Running -> Concluded: Jobs must go to WAITING first. > >> Ready -> Concluded: Jobs must go to WAITING fisrt. > > > > s/fisrt/first/ > > > >> +++ b/blockjob.c > > > >> @@ -3934,6 +3938,29 @@ > >> 'offset': 'int', > >> 'speed' : 'int' } } > >> +## > >> +# @BLOCK_JOB_WAITING: > >> +# > >> +# Emitted when a block job that is part of a transction has stopped > >> work and is > > > > s/transction/transaction/ > > > >> +# waiting for other jobs in the transaction to reach the same state. > > > > Is this event emitted only for 'new-style' transactions (old drivers > > will never see it, because they don't request new style), or always (old > > drivers will see, but presumably ignore, it)? > > > > ...! Actually, I meant to remove the WAITING *event* entirely, this is a > mistake. > > It's purely an informational state that clients likely cannot make any > real use of, because regardless of old or new style, jobs will > transition automatically to "PENDING." > > That said, old or new, the state is visible from query-block-jobs. It means that the block job isn't working any more, which could possibly be useful information. Umm... When mirror transitions into WAITING, it stops working, but doesn't change the graph yet. Isn't that a problem? Currently it doesn't cause bugs because mirror doesn't support transactions, but we should design things so that mirror could become transactionable later on. I suppose one way to achieve this would be that mirror only transitions into WAITING when the whole transaction is ready to move forward. In this case, block-job-complete wouldn't tell mirror any more to actually complete, but just to signal that the user is ready to have this job completed. Essentially this would split READY in two: The first state is when the job has completed the bulk job and waits for the user, and the second state is after the user sent block-job-complete. The second state automatically transitions into WAITING as soon as all other jobs in the transaction are either WAITING or in the second READY state. Alternatively, mirror jobs could stay active in the WAITING phase, which would then become the second READY phase. In this case, the state machine would stay as it is, just the semantics of WAITING would change. The result is either way that the WAITING event becomes uninteresting, so after all I think I agree with completely removing it. Kevin
diff --git a/blockjob.c b/blockjob.c index 1c010ec100..4aed86fc6b 100644 --- a/blockjob.c +++ b/blockjob.c @@ -44,26 +44,27 @@ static QemuMutex block_job_mutex; /* BlockJob State Transition Table */ bool BlockJobSTT[BLOCK_JOB_STATUS__MAX][BLOCK_JOB_STATUS__MAX] = { - /* U, C, R, P, Y, S, X, E, N */ - /* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0, 0, 0, 0}, - /* C: */ [BLOCK_JOB_STATUS_CREATED] = {0, 0, 1, 0, 0, 0, 0, 0, 1}, - /* R: */ [BLOCK_JOB_STATUS_RUNNING] = {0, 0, 0, 1, 1, 0, 1, 1, 0}, - /* P: */ [BLOCK_JOB_STATUS_PAUSED] = {0, 0, 1, 0, 0, 0, 0, 0, 0}, - /* Y: */ [BLOCK_JOB_STATUS_READY] = {0, 0, 0, 0, 0, 1, 1, 1, 0}, - /* S: */ [BLOCK_JOB_STATUS_STANDBY] = {0, 0, 0, 0, 1, 0, 0, 0, 0}, - /* X: */ [BLOCK_JOB_STATUS_ABORTING] = {0, 0, 0, 0, 0, 0, 0, 1, 0}, - /* E: */ [BLOCK_JOB_STATUS_CONCLUDED] = {0, 0, 0, 0, 0, 0, 0, 0, 1}, - /* N: */ [BLOCK_JOB_STATUS_NULL] = {0, 0, 0, 0, 0, 0, 0, 0, 0}, + /* U, C, R, P, Y, S, W, X, E, N */ + /* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0, 0, 0, 0, 0}, + /* C: */ [BLOCK_JOB_STATUS_CREATED] = {0, 0, 1, 0, 0, 0, 0, 0, 0, 1}, + /* R: */ [BLOCK_JOB_STATUS_RUNNING] = {0, 0, 0, 1, 1, 0, 1, 1, 0, 0}, + /* P: */ [BLOCK_JOB_STATUS_PAUSED] = {0, 0, 1, 0, 0, 0, 0, 0, 0, 0}, + /* Y: */ [BLOCK_JOB_STATUS_READY] = {0, 0, 0, 0, 0, 1, 1, 1, 0, 0}, + /* S: */ [BLOCK_JOB_STATUS_STANDBY] = {0, 0, 0, 0, 1, 0, 0, 0, 0, 0}, + /* W: */ [BLOCK_JOB_STATUS_WAITING] = {0, 0, 0, 0, 0, 0, 0, 1, 1, 0}, + /* X: */ [BLOCK_JOB_STATUS_ABORTING] = {0, 0, 0, 0, 0, 0, 0, 0, 1, 0}, + /* E: */ [BLOCK_JOB_STATUS_CONCLUDED] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 1}, + /* N: */ [BLOCK_JOB_STATUS_NULL] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, }; bool BlockJobVerbTable[BLOCK_JOB_VERB__MAX][BLOCK_JOB_STATUS__MAX] = { - /* U, C, R, P, Y, S, X, E, N */ - [BLOCK_JOB_VERB_CANCEL] = {0, 1, 1, 1, 1, 1, 0, 0, 0}, - [BLOCK_JOB_VERB_PAUSE] = {0, 1, 1, 1, 1, 1, 0, 0, 0}, - [BLOCK_JOB_VERB_RESUME] = {0, 1, 1, 1, 1, 1, 0, 0, 0}, - [BLOCK_JOB_VERB_SET_SPEED] = {0, 1, 1, 1, 1, 1, 0, 0, 0}, - [BLOCK_JOB_VERB_COMPLETE] = {0, 0, 0, 0, 1, 0, 0, 0, 0}, - [BLOCK_JOB_VERB_DISMISS] = {0, 0, 0, 0, 0, 0, 0, 1, 0}, + /* U, C, R, P, Y, S, W, X, E, N */ + [BLOCK_JOB_VERB_CANCEL] = {0, 1, 1, 1, 1, 1, 1, 0, 0, 0}, + [BLOCK_JOB_VERB_PAUSE] = {0, 1, 1, 1, 1, 1, 0, 0, 0, 0}, + [BLOCK_JOB_VERB_RESUME] = {0, 1, 1, 1, 1, 1, 0, 0, 0, 0}, + [BLOCK_JOB_VERB_SET_SPEED] = {0, 1, 1, 1, 1, 1, 0, 0, 0, 0}, + [BLOCK_JOB_VERB_COMPLETE] = {0, 0, 0, 0, 1, 0, 0, 0, 0, 0}, + [BLOCK_JOB_VERB_DISMISS] = {0, 0, 0, 0, 0, 0, 0, 0, 1, 0}, }; static void block_job_state_transition(BlockJob *job, BlockJobStatus s1) @@ -587,6 +588,8 @@ static void block_job_completed_txn_success(BlockJob *job) BlockJob *other_job; int rc = 0; + block_job_state_transition(job, BLOCK_JOB_STATUS_WAITING); + /* * Successful completion, see if there are other running jobs in this * txn. diff --git a/qapi/block-core.json b/qapi/block-core.json index b42796a6a0..3005aac7e2 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -998,6 +998,10 @@ # @standby: The job is ready, but paused. This is nearly identical to @paused. # The job may return to @ready or otherwise be canceled. # +# @waiting: The job is waiting for other jobs in the transaction to converge +# to the waiting state. This status will likely not be visible for +# the last job in a transaction. +# # @aborting: The job is in the process of being aborted, and will finish with # an error. The job will afterwards report that it is @concluded. # This status may not be visible to the management process. @@ -1012,7 +1016,7 @@ ## { 'enum': 'BlockJobStatus', 'data': ['undefined', 'created', 'running', 'paused', 'ready', 'standby', - 'aborting', 'concluded', 'null' ] } + 'waiting', 'aborting', 'concluded', 'null' ] } ## # @BlockJobInfo: @@ -3934,6 +3938,29 @@ 'offset': 'int', 'speed' : 'int' } } +## +# @BLOCK_JOB_WAITING: +# +# Emitted when a block job that is part of a transction has stopped work and is +# waiting for other jobs in the transaction to reach the same state. +# +# @type: job type +# +# @id: The job identifier. +# +# Since: 2.12 +# +# Example: +# +# <- { "event": "BLOCK_JOB_WAITING", +# "data": { "id": "drive0", "type": "mirror" }, +# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } } +# +## +{ 'event': 'BLOCK_JOB_WAITING', + 'data': { 'type' : 'BlockJobType', + 'id' : 'str' } } + ## # @PreallocMode: #
For jobs that are stuck waiting on others in a transaction, it would be nice to know that they are no longer "running" in that sense, but instead are waiting on other jobs in the transaction. Jobs that are "waiting" in this sense cannot be meaningfully altered any longer as they have left their running loop. The only meaningful user verb for jobs in this state is "cancel," which will cancel the whole transaction, too. Transitions: Running -> Waiting: Normal transition. Ready -> Waiting: Normal transition. Waiting -> Aborting: Transactional cancellation. Waiting -> Concluded: Normal transition. Removed Transitions: Running -> Concluded: Jobs must go to WAITING first. Ready -> Concluded: Jobs must go to WAITING fisrt. Verbs: Cancel: Can be applied to WAITING jobs. +---------+ |UNDEFINED| +--+------+ | +--v----+ |CREATED+-----------------+ +--+----+ | | | +--v----+ +------+ | +---------+RUNNING<----->PAUSED| | | +--+-+--+ +------+ | | | | | | | +------------------+ | | | | | | +--v--+ +-------+ | | +---------+READY<------->STANDBY| | | | +--+--+ +-------+ | | | | | | | +--v----+ | | +---------+WAITING<---------------+ | | +--+----+ | | | | +--+-----+ +--v------+ | |ABORTING+--->CONCLUDED| | +--------+ +--+------+ | | | +--v-+ | |NULL<--------------------+ +----+ Signed-off-by: John Snow <jsnow@redhat.com> --- blockjob.c | 37 ++++++++++++++++++++----------------- qapi/block-core.json | 29 ++++++++++++++++++++++++++++- 2 files changed, 48 insertions(+), 18 deletions(-)