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

10.06.2021 17:04, Eric Blake wrote: 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