On 06/02/2017 10:26 AM, Vladimir Sementsov-Ogievskiy wrote: > 30.05.2017 17:53, Eric Blake wrote: >> On 05/30/2017 05:48 AM, Vladimir Sementsov-Ogievskiy wrote: >>> The function should collect statistics, about allocted/unallocated by >>> top-level format driver space (in its .file) and allocation status >>> (allocated/hole/after eof) of corresponding areas in this .file. >>>
>>> +# @BlockFormatAllocInfo:
>>> +#
>>> +# Information about allocations, including metadata. All fields are
>>> in bytes.
>
> s/All fields are in bytes./All fields are in bytes and aligned by sector
> (512 bytes)./
I wouldn't even promise sector alignment. We probably happen to have
sector alignment (especially for qcow2, since the smallest cluster size
permitted is sector aligned), but I see no inherent reason why we can't
support sub-sector values if we are reporting in bytes.
>
> - ok? to emphasize that there is nothing about clusters... Or may be
> better to write that they are aligned by byte.
I think "All fields are in bytes" is sufficient.
>>> +{ 'struct': 'BlockFormatAllocInfo',
>>> + 'data': {'alloc_alloc': 'uint64',
>>> + 'alloc_hole': 'uint64',
>>> + 'alloc_overhead': 'uint64',
>>> + 'hole_alloc': 'uint64',
>>> + 'hole_hole': 'uint64' } }
>> The idea seems okay, but the naming needs to be fixed. Also, I'm not
>> sure if we need all 5, or if 4 is enough; and I'm not sure if we have
>> the right names ("how does alloc-hole differ from hole-alloc?"), or if
>> we can come up with something more descriptive. Particularly since
>> "hole-" is not a hole in the filesystem sense, so much as unused
>> clusters. But I'm also not coming up with better names to suggest at
>> the moment.
>>
> how about:
>
> used-allocated
> used-discarded
> used-overrun
>
> unused-allocated
> unused-discarded
Those work for me.
>
>
> also, do you mention that your detailed wordings should be included into
> block-core.json or you just clarify things?
Good documentation is worth the effort. I don't know if you want all of
my details in block-core.json, but giving a better overview of how each
statistic is possible does make it easier to visualize what the
statistic is actually counting.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
