Re: [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