On 13.08.19 16:46, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 17:31, Max Reitz wrote:
>> On 13.08.19 13:51, Kevin Wolf wrote:
>>
>> [...]
>>
>>> Hm... This is a mess. :-)
>>
>> Just out of curiosity: Why?
>>
>> Aren’t there only two things we really need from the block_status
>> infrastructure?
>>
>> (1) Whether something is allocated in the given layer of the backing chain,
>>
>> (2) Whether we know that a given range reads as zeroes.
>>
>> Do we really need anything else?
>>
> 
> qemu-img map?

Which is a debugging tool.  So it doesn’t fall under “really” in my
book.  If removing everything but allocation+zero information would make
the code a lot simpler, I think that would be worth it.

> 1. We need to fix the bug somehow
> 2. We need to fix comment about different block-status flags, as it really
> lacks information of what actually "DATA" means (together with *file).
> And what finally means "allocated", can you define it precisely?

As I wrote in my other mails, I think the problem is that it’s just
unexpected that block_status automatically skips through for filters.
It shouldn’t, that’s just black magic that the caller should not rely on.

(We see precisely here that it’s wrong, because the callers are not
prepared for the allocation information returned to be associated with a
different node than what they passed.)

So my definition is just “If the node has a COW backing file and
block_status returns ‘not allocated’, the data will be there.
Otherwise, the data is in the current node.”  Yes, that means that
filters should appear as fully allocated.

Max

> 3. Fix nbd-server to be closer to NBD spec about block-status
> 
> I made several tries to imagine [1] and [2] but never succeeded..
> 
>