19.12.2019 13:20, Vladimir Sementsov-Ogievskiy wrote:
19.12.2019 13:13, Kevin Wolf wrote:
Am 19.12.2019 um 10:24 hat Vladimir Sementsov-Ogievskiy geschrieben:
10.12.2019 20:46, Kevin Wolf wrote:
Am 22.11.2019 um 17:05 hat Kevin Wolf geschrieben:
See patch 4 for the description of the bug fixed.
I'm applying patches 3 and 5-7 to the block branch because they make
sense on their own.
The real fix will need another approach because the error handling is
broken in this one: If zeroing out fails (either because of NO_FALLBACK
or because of some other I/O error), bdrv_co_truncate() will return
failure, but the image size has already been increased, with potentially
incorrect data in the new area.
To fix this, we need to make sure that zeros will be read before we
commit the new image size to the image file (e.g. qcow2 header) and to
bs->total_sectors. In other words, it must become the responsibility of
the block driver.
To this effect, I'm planning to introduce a PREALLOC_MODE_ZERO_INIT flag
that can be or'ed to the preallocation mode. This will fail by default
because it looks like just another unimplemented preallocation mode to
block drivers. It will be requested explicitly by commit jobs and
automatically added by bdrv_co_truncate() if the backing file would
become visible (like in this series, but now for all preallocation
modes). I'm planning to implement it for qcow2 and file-posix for now,
which should cover most interesting cases.
Does this make sense to you?
This should work. Do you still have this plan in a timeline?
Still planning to do this, but tomorrow is my last working day for this
year. So I guess I'll get to it sometime in January.
Good. Have a nice holiday!
Hi, didn't you forget? I just going to ping (or resend) my related
"[PATCH 0/4] fix & merge block_status_above and is_allocated_above", so,
pinging these patches too...
--
Best regards,
Vladimir
