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.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
---
block.c | 16 ++++++++++++++++
include/block/block.h | 3 +++
include/block/block_int.h | 2 ++
qapi/block-core.json | 26 ++++++++++++++++++++++++++
4 files changed, 47 insertions(+)
diff --git a/block.c b/block.c
index 50ba264143..7d720ae0c2 100644
--- a/block.c
+++ b/qapi/block-core.json
@@ -139,6 +139,32 @@
'*format-specific': 'ImageInfoSpecific' } }
##
+# @BlockFormatAllocInfo:
+#
+# Information about allocations, including metadata. All fields are in bytes.
+#
+# @alloc_alloc: allocated by format driver and allocated in underlying file
+#
New structs should favor naming with '-' rather than '_'. So this should
be 'alloc-alloc', if we like the name.
So this statistic represents the portions of the format file that are in
use by the format, and which are backed by data in the underlying protocol.
+# @alloc_hole: allocated by format driver but actually is a hole in
+# underlying file
The portions of the format file in use by the format, but where the
entire cluster is a hole in the underlying file (note that with cluster
size large enough, you can get a cluster that is part-data/part-hole in
the underlying file, it looks like you are counting those as data).
+#
+# @alloc_overhead: allocated by format driver after end of underlying file
The portions of the format file in use by the format, but where the
entire cluster is beyond the end of the underlying file (the effective
hole). Do we really need to distinguish between hole within the
underlying file and hole beyond the end of the file? Or can this number
be combined with the previous?
+#
+# @hole_alloc: not allocated by format driver but allocated in underlying file
I'm not sure I like this name. "Hole" in file-system terminology means
"reads-as-zero" - but here we are talking about portions of the format
layer that are unallocated (defer to backing file, and we can't
guarantee they read as zero unless there is no backing file).
This statistic represents the portion of the underlying file that has
been previously allocated to hold data, but which is now unused by the
format layer (in other words, leaked clusters that can be reclaimed, or
which can be reused instead of growing the underlying the file if new
clusters are allocated).
+#
+# @hole_hole: not allocated by format driver hole in underlying file
This statistic represents fragmentation - portions of the format layer
that are no longer in use, but which are also occupying no space in the
underlying file. A refragmentation operation (if we ever implemented
one) could remove the address space used by these clusters, but would
not change the disk usage.
+#
+# Since: 2.10
+#
+##
+{ '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.