From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Eric Blake <eblake@redhat.com>, Nir Soffer <nsoffer@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block <qemu-block@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>,
libguestfs@redhat.com
Subject: Re: [PATCH 2/2] nbd: Add new qemu:joint-allocation metadata context
Date: Thu, 10 Jun 2021 17:43:05 +0300 [thread overview]
Message-ID: <c43863ed-9638-53f6-10d0-e3754f803a8e@virtuozzo.com> (raw)
In-Reply-To: <20210610140400.s5bprikdunfkc5uh@redhat.com>
10.06.2021 17:04, Eric Blake wrote:
> Maybe the thing to do is improve the documentation and try to avoid
> ambiguous terminalogy; in qemu:allocation-depth, a return of depth 0
> should be called "absent", not "unallocated". And in libnbd, a
> base:allocation of 0 should be "data" or "normal", not "allocated".
Interesting, how many problems, misunderstanding and confusion we have for years because of that terminology :)
Funny, that we try to imagine how to call these thing in general, but actually in 99.99% cases we are saying about only 5 simple things:
file-posix data
file-posix hole
qcow2 DATA
qcow2 ZERO
qcow2 UNALLOCATED
And all our problems comes from our trying to divide these thing into two categories: allocated/unallocated. But it never worked.
I'd divide like this:
DATA
examples:
- data cluster in qcow2
- data region in file-posix
properties:
- data actually occupies space on disk
- io operations are handled by this layer, backing is shadowed
- write should not increase disk occupation
GO_TO_BACKING
examples:
- "unallocated" cluster in qcow2
properties
- read from backing image (if no backing, read zeroes)
- disk occupation status is known only by backing image (if no backing, disk is not occupied)
- write will allocate new cluster in top image, which will increase disk occupation
ZERO
examples:
- zero cluster in qcow2, no space is occupied (most probably), reads as zeroes
- file-posix hole, no space is occupied (most probably), reads as zeroes
properties:
- read zeroes
- io operations are handled by this layer, backing is shadowed
- no space is occupied (most probably)
- write should not increase disk occupation (most probably)
We can consider qcow2 ALLOCATED_ZERO also, and maybe SCSI unallocated which means that nothing is occupied but read doesn't guarantee zeroes.. But that doesn't really matter. What does matter is that trying to describe qcow2 backing files in usual block terms allocated/unallocated zero/data never worked good. So in a good documentation (and good code) we should describe (and handle) qcow2 backing chains as qcow2 backing chains and don't try to shadow them under usual terminology.
--
Best regards,
Vladimir
next prev parent reply other threads:[~2021-06-10 14:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 18:01 [RFC PATCH 0/2] New NBD metacontext Eric Blake
2021-06-09 18:01 ` [PATCH 1/2] iotests: Improve and rename test 309 to nbd-qemu-allocation Eric Blake
2021-06-10 12:14 ` Vladimir Sementsov-Ogievskiy
2021-06-09 18:01 ` [PATCH 2/2] nbd: Add new qemu:joint-allocation metadata context Eric Blake
2021-06-09 23:52 ` Nir Soffer
2021-06-10 12:30 ` Vladimir Sementsov-Ogievskiy
2021-06-10 13:47 ` Eric Blake
2021-06-10 14:10 ` Vladimir Sementsov-Ogievskiy
2021-06-10 13:16 ` Nir Soffer
2021-06-10 14:04 ` Eric Blake
2021-06-10 14:43 ` Vladimir Sementsov-Ogievskiy [this message]
2021-06-10 13:31 ` Eric Blake
2021-06-11 23:39 ` Nir Soffer
2021-06-14 13:56 ` Eric Blake
2021-06-14 14:06 ` Nir Soffer
2021-06-09 21:31 ` [RFC libnbd PATCH] info: Add support for new qemu:joint-allocation Eric Blake
2021-06-09 22:20 ` Nir Soffer
2021-06-10 13:06 ` Eric Blake
2021-06-10 13:19 ` Nir Soffer
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=c43863ed-9638-53f6-10d0-e3754f803a8e@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=libguestfs@redhat.com \
--cc=mreitz@redhat.com \
--cc=nsoffer@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 read-only IMAP folder(s) and NNTP newsgroup(s).