Re: [PATCH 1/5] iotests: Update 241 to expose backing layer fragmentation

[Vladimir Sementsov-Ogievskiy]

25.02.2021 18:52, Eric Blake wrote:
> On 2/25/21 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> > 25.02.2021 16:50, Vladimir Sementsov-Ogievskiy wrote:
> > > 18.02.2021 23:15, Eric Blake wrote:
> > > > Previous commits (such as 6e280648, 75d34eb9) have mentioned that our
> > > > NBD server still sends unaligned fragments when an active layer with
> > > > large advertised minimum block size is backed by another layer with a
> > > > smaller block size. Expand the test to actually cover these scenario,
> > > > by using two different approaches: qcow2 encryption (which forces
> > > > 512-byte alignment) with an unaligned raw backing file, and blkdebug
> > > > with a 4k alignment.
>
> > Now I don't think that aligning qemu:allocation-depth information is a
> > correct thing to do.
>
> Why not?  First, it's very rare that you'd have a qcow2 image with
> mandated 4k minimum block size, backed by another qcow2 image with 512
> block size (blkdebug made it possible to expose the bug, but I could not
> find a way in common day-to-day usage), so we really aren't impacting
> normal users.  Second, from the perspective of copying backing chains
> over NBD, what difference does it make if we have the backing chain:
>
> A (granularity 512) <- B (granularity 512) <- C (granularity 4k)
>
> with the allocation pattern:
>
> A: -A-A-A-A-A-A-A-A
> B: --BB--BB--BB--BB
> C: --------CCCCCCCC
>
> and report the allocation depth as:
>
>     2222222211111111
>
> instead of
>
>     0322032211111111
>
> The former may be imprecise, but it obeys our bounds, and in all
> reality, if all we have access to is 4k chunks, any decisions we make
> about how to handle that 4k block should be based on the fact that at
> least some of the data was allocated in our backing file, and not
> treating the entire 4k as unallocated merely because the first 512 bytes
> are neither in A nor B.

I'm not sure about NBD client, but in qemu block-jobs the decision may be 
different for different tasks, as I mentioned in my answer on [2/5].
For example block-stream will skip chunks allocated in top, because nothing to 
do, data is already in top. But if we imagine that top may return ALLOCATED for 
something that is not ALLOCATED the stream logic is broken.. Probably that's a 
bad example.

I agree that this is a rare case anyway and we probably shouldn't care too 
much. But we should at least describe it in allocation-depth specification.


--
Best regards,
Vladimir