[Libguestfs] [PATCH 2/2] nbd: Add new qemu:joint-allocation metadata context

[Vladimir Sementsov-Ogievskiy]

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