From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: eblake@redhat.com, armbru@redhat.com, mreitz@redhat.com,
kwolf@redhat.com, vsementsov@virtuozzo.com, den@openvz.org
Subject: [Qemu-devel] [PATCH v4 0/3] qemu-img check: format allocation info
Date: Sat, 29 Jul 2017 19:41:01 +0300 [thread overview]
Message-ID: <20170729164104.29537-1-vsementsov@virtuozzo.com> (raw)
Hi all.
See 01 patch for the doc.
Question to discuss.
If I understand correctly get_block_status flags allocated, zero, and data
actually provide 5 possible combinations, which I combine into three.
allocated data zero
1 1 1 \__ data
1 1 0 /
1 0 1 \__ zero
0 0 1 /
0 0 0 ___ discarded
This division looks not bad, but it is not the only one possible.
Separating data is really useful - it shows leaked clusters..
So the question is, don't we want to adjust the division?
I'm ok with the current one.
v4: - reword docs in 01
- s/2.10/2.11/ for qapi
v3: - improve docs
- rename fields
- add 'zero' type of underlying file portions status. It as these
areas cannot be presented as 'discarded', but they are not
occupying real space, so we don't want to present them as
'allocated data' too.
- remove last patch. It is not needed after introducing new naming
for the fields
v2: fix build error, gcc things that some variables may be used
uninitialized (actually they didn't).
v1:
These series is a replacement for "qemu-img check: unallocated size"
series.
There was a question, should we account allocated clusters in qcow2 but
actually holes in underalying file as allocated or not. Instead of
hiding this information in one-number statistic I've decided to print
the whole information, 5 numbers:
For allocated by top-level format driver (qcow2 for ex.) clusters, 3
numbers: number of bytes, which are:
- allocated in underlying file
- holes in underlying file
- after end of underlying file
To account other areas of underlying file, 2 more numbers of bytes:
- unallocated by top-level driver but allocated in underlying file
- unallocated by top-level driver and holes in underlying file
Vladimir Sementsov-Ogievskiy (3):
block: add bdrv_get_format_alloc_stat format interface
qcow2: add .bdrv_get_format_alloc_stat
qemu-img check: add format allocation info
block.c | 16 +++++
block/qcow2-refcount.c | 152 ++++++++++++++++++++++++++++++++++++++++++++++
block/qcow2.c | 2 +
block/qcow2.h | 2 +
include/block/block.h | 3 +
include/block/block_int.h | 2 +
qapi/block-core.json | 78 +++++++++++++++++++++++-
qemu-img.c | 42 +++++++++++++
8 files changed, 296 insertions(+), 1 deletion(-)
--
2.11.1
next reply other threads:[~2017-07-29 16:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-29 16:41 Vladimir Sementsov-Ogievskiy [this message]
2017-07-29 16:41 ` [Qemu-devel] [PATCH v4 1/3] block: add bdrv_get_format_alloc_stat format interface Vladimir Sementsov-Ogievskiy
2017-08-14 14:50 ` Markus Armbruster
2017-07-29 16:41 ` [Qemu-devel] [PATCH v4 2/3] qcow2: add .bdrv_get_format_alloc_stat Vladimir Sementsov-Ogievskiy
2017-07-29 16:41 ` [Qemu-devel] [PATCH v4 3/3] qemu-img check: add format allocation info Vladimir Sementsov-Ogievskiy
2017-08-14 14:53 ` Markus Armbruster
2017-07-31 15:14 ` [Qemu-devel] [PATCH v4 0/3] qemu-img check: " Eric Blake
2017-07-31 15:43 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170729164104.29537-1-vsementsov@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).