[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH 0/4 for-3.0?] NBD fixes for unalign
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH 0/4 for-3.0?] NBD fixes for unaligned images |
Date: |
Mon, 10 Sep 2018 14:35:11 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
On 9/10/18 2:25 PM, John Snow wrote:
Hi, has this series been superseded or do we need a respin for 3.1?
Needs a respin.
There are two issues still to be solved:
1. Asking the top-most block layer for its alignment isn't necessarily
right for qemu as server. If we have:
backing (512) <- active (4k)
and tell the client that they can't access anything smaller than 4k
granularity, but then read through to the backing layer which does just
that, then we're wrong. Either the block layer has to be beefed up to
make bdrv_block_status() round backing file's smaller granularity into
the size we advertised (perhaps by adding a flag to bdrv_block_status()
to declare whether we prefer the most accurate information vs. the
rounded information) - or else qemu as NBD server should ALWAYS
advertise a blocksize of 1-512 (1 because we can, even if by
read-modify-write; or 512 because except for EOF issues on a
non-sector-aligned file, we don't encounter mid-sector transitions
anywhere else, and EOF is easier to special case than everywhere).
2. Patch 5 fixes qemu as client to not round valid requests past EOF,
but does not fix the case of a request that intentionally exceeds EOF
but fits within the rounded file size from reaching the server. Either
the NBD client code should itself perform EOF validation (reads from the
EOF hole see zero, writes of anything other than zero fail with ENOSPC),
or the NBD client code should round the server's file size down instead
of up. I haven't decided which approach is better.
But right now, these fixes are taking a back seat to me trying to get a
libvirt incremental backup demo working.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org