Hanna Czenczek <[email protected]> writes: > On 23.10.26 08:04, Markus Armbruster wrote: >> Hanna Czenczek <[email protected]> writes: >> >>> On 20.10.26 07:59, Markus Armbruster wrote: >>>> Hanna Czenczek <[email protected]> writes: >>>> >>>>> This enum gives more information than IoOperationType (which is used for >>>>> the rerror/werror distinction) to identify operation types for block >>>>> accounting. >>>>> >>>>> Signed-off-by: Hanna Czenczek <[email protected]> >>>>> --- >>>>> qapi/block.json | 20 ++++++++++++++++++++ >>>>> 1 file changed, 20 insertions(+) >>>>> >>>>> diff --git a/qapi/block.json b/qapi/block.json >>>>> index 0a88d405a26..8f4a71733c1 100644 >>>>> --- a/qapi/block.json >>>>> +++ b/qapi/block.json >>>>> @@ -629,3 +629,23 @@ >>>>> 'command': 'str' }, >>>>> 'features': [ 'unstable' ], >>>>> 'allow-preconfig': true } >>>>> + >>>>> +## >>>>> +# @IoAccountingOperation: >>>>> +# >>>>> +# I/O operation types as they are tracked by block accounting. >>>> Can we have a link to suitable docs on block accounting? >>> >>> Which do you have in mind? >> >> Hey, I asked first! > > :) > >> Two ideas to find candidates: >> >> 1. How is IoAccountingOperation going to be used? >> >> I can see events BLOCK_IO_DELAY and BLOCK_IO_DONE. Documentation >> there calls it "disk operation" in the event description and "I/O >> operation" in the argument description. Not a peep about >> "accounting". Might "tracked by block accounting" be about >> implementation? Or asked differently: why would the user care about >> block accounting here? > > Good question, the user presumably indeed won’t care. It is only going to be > used for those two events, so maybe it makes most sense to merge those three > patches (`IoAccountingOperation`, `BLOCK_IO_DELAY`, `BLOCK_IO_DONE`), so I > can immediately refer to those events instead of accounting.
You could also add the enum without a reference, then add references as you go. Not sure whether pointing that out in the enum's commit message would be advisable. > (The internal reasoning is that I don’t want this to deviate from the > existing accounting too much, so that maybe the accounting code can later be > switched to use the same request boundaries as this series introduces, and > then switch its enum over to this QAPI variant. But absolutely not relevant > to users, correct.) > >> 2. Assuming "block accounting" is actually relevant for the user: what >> are the QMP interfaces related to it? > > The best is probably the `BlockDeviceStats` keys for the different latency > histograms, which could be a map of this new enum to histograms instead… But > given the above, probably best to just drop this. Makes sense to me. Thanks! [...]
