Am 05.05.2020 um 11:16 hat Alberto Garcia geschrieben:
> On Tue 05 May 2020 10:54:12 AM CEST, Kevin Wolf wrote:
> > But I think there is a more important problem with the test: It seems
> > to pass even with old binaries that don't have the fix. Is this only
> > on my system or do you get the same?
Am 05.05.2020 um 10:54 hat Kevin Wolf geschrieben:
> Am 04.05.2020 um 19:07 hat Alberto Garcia geschrieben:
> > On Mon 04 May 2020 06:01:19 PM CEST, Eric Blake wrote:
> > >> +_supported_fmt qcow2
> > >> +_supported_proto file
> > >
> > > Do we have to limit it to qcow2 and file? Yes, it's testing
On Tue 05 May 2020 10:54:12 AM CEST, Kevin Wolf wrote:
> But I think there is a more important problem with the test: It seems
> to pass even with old binaries that don't have the fix. Is this only
> on my system or do you get the same?
With old binaries when qcow2_cluster_zeroize() is called it r
Am 04.05.2020 um 19:07 hat Alberto Garcia geschrieben:
> On Mon 04 May 2020 06:01:19 PM CEST, Eric Blake wrote:
> >> +_supported_fmt qcow2
> >> +_supported_proto file
> >
> > Do we have to limit it to qcow2 and file? Yes, it's testing a bugfix
> > for qcow2, but are there other formats that it doe
Patchew URL: https://patchew.org/QEMU/20200504155217.10325-1-be...@igalia.com/
Hi,
This series failed build test on FreeBSD host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that h
On Mon 04 May 2020 06:01:19 PM CEST, Eric Blake wrote:
>> +_supported_fmt qcow2
>> +_supported_proto file
>
> Do we have to limit it to qcow2 and file? Yes, it's testing a bugfix
> for qcow2, but are there other formats that it doesn't hurt to have
> the extra testing?
It doesn't work with any ot
On 5/4/20 10:52 AM, Alberto Garcia wrote:
After commit f01643fb8b47e8a70c04bbf45e0f12a9e5bc54de when an image is
extended and BDRV_REQ_ZERO_WRITE is set then the new clusters are
zeroized.
The code however does not detect correctly situations when the old and
the new end of the image are within
After commit f01643fb8b47e8a70c04bbf45e0f12a9e5bc54de when an image is
extended and BDRV_REQ_ZERO_WRITE is set then the new clusters are
zeroized.
The code however does not detect correctly situations when the old and
the new end of the image are within the same cluster. The problem can
be reprodu
