Am 22.10.2014 um 20:20 schrieb Eric Blake: > On 10/22/2014 07:21 AM, Peter Lieven wrote: >> Signed-off-by: Peter Lieven <p...@kamp.de> >> Reviewed-by: Max Reitz <mre...@redhat.com> >> --- >> block.c | 2 ++ >> block/accounting.c | 7 +++++++ >> block/qapi.c | 2 ++ >> hmp.c | 6 +++++- >> include/block/accounting.h | 3 +++ >> qapi/block-core.json | 9 ++++++++- >> 6 files changed, 27 insertions(+), 2 deletions(-) >> >> +++ b/qapi/block-core.json >> @@ -392,13 +392,20 @@ >> # growable sparse files (like qcow2) that are used on >> top >> # of a physical device. >> # >> +# @rd_merged: Reserved (Since 2.2) > Does this mean it is always output as 0 for now, but may be non-zero at > some future date if we figure out how to do merged read requests? Is it > even worth adding the field if it has no semantics? We can always add > it later when it makes sense, and a client can be smart enough to > realize that a missing field is the same as the field being present with > value 0 (since that is what clients already have to do for 2.1). > > I'd feel better with just a bit more documentation or else omitting the > field. The rest of the patch is okay, though. >
Read merging is no magic. I plan to integrate it for 2.3. There are a few open questions where and how to implement it, but this can be solved. The idea was to give people the change to implement read and write merging statistics at the same time. But you are right, there should be more comments or the fields should not be published yet. Peter
