[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/5] iotests: Update 241 to expose backing layer fragmentatio
From: |
Eric Blake |
Subject: |
Re: [PATCH 1/5] iotests: Update 241 to expose backing layer fragmentation |
Date: |
Thu, 25 Feb 2021 09:52:53 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[PATCH 2/5] block: Fix BDRV_BLOCK_RAW status to honor alignment, Eric Blake, 2021/02/18
[PATCH 5/5] do not apply: Revert "nbd-client: Work around server BLOCK_STATUS misalignment at EOF", Eric Blake, 2021/02/18
[PATCH 4/5] nbd/server: Avoid unaligned dirty-bitmap status, Eric Blake, 2021/02/18
[PATCH 3/5] nbd/server: Avoid unaligned read/block_status from backing, Eric Blake, 2021/02/18
Re: [PATCH 0/5] Obey NBD spec regarding block size bounds on reply, no-reply, 2021/02/18