23.04.2020 18:01, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
tests/qemu-iotests/274 | 157 ++
tests/qemu-iotests/274.out | 260 +
tests/qemu-iotests/group | 1 +
3 files changed, 418 insertions(+)
On 24.04.20 00:17, Eric Blake wrote:
> There are several callers that need to create a new block backend from
> an existing BDS; make the task slightly easier with a common helper
> routine.
>
> Suggested-by: Max Reitz
> Signed-off-by: Eric Blake
> ---
> include/sysemu/block-backend.h | 2 ++
>
On 24.04.20 11:53, Max Reitz wrote:
> On 24.04.20 00:17, Eric Blake wrote:
>> There are several callers that need to create a new block backend from
>> an existing BDS; make the task slightly easier with a common helper
>> routine.
>>
>> Suggested-by: Max Reitz
>> Signed-off-by: Eric Blake
>> ---
On 24.04.20 11:56, Max Reitz wrote:
> On 24.04.20 11:53, Max Reitz wrote:
>> On 24.04.20 00:17, Eric Blake wrote:
>>> There are several callers that need to create a new block backend from
>>> an existing BDS; make the task slightly easier with a common helper
>>> routine.
>>>
>>> Suggested-by: Max
On 4/16/20 8:03 AM, Klaus Birkelund Jensen wrote:
On Apr 15 15:26, Philippe Mathieu-Daudé wrote:
On 4/15/20 3:20 PM, Klaus Birkelund Jensen wrote:
I'll get the v1.3 series ready next.
Cool. What really matters (to me) is seeing tests. If we can merge tests
(without multiple namespaces) befo
On 24.04.20 00:17, Eric Blake wrote:
> Our comment did not actually match the code. Rewrite the comment to
> be less sensitive to any future changes to qcow2-bitmap.c that might
> implement scenarios that we currently reject.
>
> Signed-off-by: Eric Blake
> ---
> block/qcow2.c | 2 +-
> 1 file
On 24.04.20 00:17, Eric Blake wrote:
> We originally refused to allow resize of images with internal
> snapshots because the v2 image format did not require the tracking of
> snapshot size, making it impossible to safely revert to a snapshot
> with a different size than the current view of the imag
Am 24.04.2020 um 08:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 23.04.2020 18:01, Kevin Wolf wrote:
> > If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
> > qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
> > undo any previous preallocation, but just
On Thu, Apr 23, 2020 at 05:17:05PM -0500, Eric Blake wrote:
> There are several callers that need to create a new block backend from
> an existing BDS; make the task slightly easier with a common helper
> routine.
>
> Suggested-by: Max Reitz
> Signed-off-by: Eric Blake
> ---
> include/sysemu/bl
The raw format driver can simply forward the flag and let its bs->file
child take care of actually providing the zeros.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/raw-format.c | 4 +++-
1 file changed, 3 inserti
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previous preallocation, but just adds the zero flag to all
relevant L2 entries. If an external data file is in use, a write_zeroes
request to the data
v7:
- Allocate smaller zero buffer [Vladimir]
- Added missing error_setg_errno() [Max]
- Code cleanup in the iotest, enabled mapping for 'metadata' [Vladimir]
- Don't assign to errp twice [Eric]
v6:
- qcow2: Don't round up end offset [Eric]
- qcow2: Use different error messages for different error
Now that block drivers can support flags for .bdrv_co_truncate, expose
the parameter in the node level interfaces bdrv_co_truncate() and
bdrv_truncate().
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
include/block/bl
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/274 | 155 +
tests/qemu-iotests/274.out | 268 +
tests/qemu-iotests/group | 1 +
3 files changed, 424 insertions(+)
create mode 100755 tests/qemu-iotests/274
create mode 100644 tests
For regular files, we always get BDRV_REQ_ZERO_WRITE behaviour from the
OS, so we can advertise the flag and just ignore it.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
block/file-posix.c | 4
1 file changed,
This adds a new BdrvRequestFlags parameter to the .bdrv_co_truncate()
driver callbacks, and a supported_truncate_flags field in
BlockDriverState that allows drivers to advertise support for request
flags in the context of truncate.
For now, we always pass 0 and no drivers declare support for any f
When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
Consider the following scenario where the overlay is shorter than its
backing file:
base.q
We want to keep TEST_IMG for the full path of the main test image, but
filter_testfiles() must be called for other test images before replacing
other things like the image format because the test directory path could
contain the format as a substring.
Insert a filter_testfiles() call between both.
Now that node level interface bdrv_truncate() supports passing request
flags to the block driver, expose this on the BlockBackend level, too.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
include/sysemu/block-backend
> On Thu, Apr 23, 2020 at 8:43 PM Dima Stepanov wrote:
>> The problem is that vhost_user_write doesn't get an error after
>> disconnect and try to call vhost_user_read(). The tcp_chr_write()
>> routine should return -1 in case of disconnect. Indicate the EIO error
>> if this routine is called in t
We should put all UNIX socket files into the sock_dir, not test_dir.
Reported-by: Elena Ufimtseva
Signed-off-by: Max Reitz
---
tests/qemu-iotests/041 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/041 b/tests/qemu-iotests/041
index 5d67bf14bf..46bf1f6c81
On 24.04.20 14:54, Kevin Wolf wrote:
> If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
> qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
> undo any previous preallocation, but just adds the zero flag to all
> relevant L2 entries. If an external data file i
On 24.04.20 14:54, Kevin Wolf wrote:
> When extending the size of an image that has a backing file larger than
> its old size, make sure that the backing file data doesn't become
> visible in the guest, but the added area is properly zeroed out.
>
> Consider the following scenario where the overla
On 24.04.20 14:54, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/274 | 155 +
> tests/qemu-iotests/274.out | 268 +
> tests/qemu-iotests/group | 1 +
> 3 files changed, 424 insertions(+)
> create mode 1007
On 24.04.20 14:54, Kevin Wolf wrote:
> v7:
> - Allocate smaller zero buffer [Vladimir]
> - Added missing error_setg_errno() [Max]
> - Code cleanup in the iotest, enabled mapping for 'metadata' [Vladimir]
> - Don't assign to errp twice [Eric]
I would have liked to see that change in patch 10, but t
On 4/24/20 7:17 AM, Kevin Wolf wrote:
+ret = qcow2_co_pwritev_part(bs, old_length, qiov.size, &qiov, 0,
0);
Better not do it if this cluster is already ZERO.. But it may be a
later patch to improve that.
I doubt it's worth writing code to optimise a corner case inside a
corner
On 4/24/20 5:02 AM, Max Reitz wrote:
(With the Patchew warning fixed, of course (i.e., we should set ret to
-EPERM or something in qcow.c))
Er, well, maybe I should have looked into more places. The compiler
only warns about that single one because it’s the only place where @ret
is really uni
The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
image is possibly preallocated and then the zero flag is added to all
clusters. This means that a copy-on-write operation may be needed when
writing to these clusters, despite having used preallocation, negating
one of the maj
On 24.04.20 16:18, Eric Blake wrote:
> On 4/24/20 5:02 AM, Max Reitz wrote:
>
>>> (With the Patchew warning fixed, of course (i.e., we should set ret to
>>> -EPERM or something in qcow.c))
>>
>> Er, well, maybe I should have looked into more places. The compiler
>> only warns about that single on
On 4/24/20 8:46 AM, Max Reitz wrote:
We should put all UNIX socket files into the sock_dir, not test_dir.
Reported-by: Elena Ufimtseva
Signed-off-by: Max Reitz
---
tests/qemu-iotests/041 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Eric Blake
I'm happy to queue th
24.04.2020 15:17, Kevin Wolf wrote:
Am 24.04.2020 um 08:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
23.04.2020 18:01, Kevin Wolf wrote:
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previo
On 24.04.20 16:27, Kevin Wolf wrote:
> The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
> image is possibly preallocated and then the zero flag is added to all
> clusters. This means that a copy-on-write operation may be needed when
> writing to these clusters, despite havin
On 4/24/20 7:54 AM, Kevin Wolf wrote:
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previous preallocation, but just adds the zero flag to all
relevant L2 entries. If an external data file is in
24.04.2020 15:54, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
[..]
+
+# After this, 0 to base_size should be allocated/zeroed.
Actually, top_size_old to base_size, yes? (sorry, nitpicking, missed on
previous review).
+#
24.04.2020 17:27, Kevin Wolf wrote:
The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
image is possibly preallocated and then the zero flag is added to all
clusters. This means that a copy-on-write operation may be needed when
writing to these clusters, despite having used
On Tue 17 Mar 2020 07:16:21 PM CET, Alberto Garcia wrote:
> Compressed clusters always have the bitmap part of the extended L2
> entry set to 0.
I was just finishing some improvements to the new code that allows
BDRV_REQ_ZERO_WRITE at the subcluster level, and I'm starting to
entertain the idea o
On 4/24/20 12:02 PM, Alberto Garcia wrote:
On Tue 17 Mar 2020 07:16:21 PM CET, Alberto Garcia wrote:
Compressed clusters always have the bitmap part of the extended L2
entry set to 0.
I was just finishing some improvements to the new code that allows
BDRV_REQ_ZERO_WRITE at the subcluster leve
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
>> 'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
>> copy on write. The compressed data would remain untouched on disk but
>> some of the subclusters would have the 'all zeroes' bit set, exactly
>> like what happens w
On 4/24/20 12:21 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
copy on write. The compressed data would remain untouched on disk but
some of the subclusters would have the 'all zeroes' bi
On Fri 24 Apr 2020 07:44:33 PM CEST, Eric Blake wrote:
>>> at the same time, I can see where you're coming from in stating that
>>> if it makes management of extended L2 easier to allow zero subclusters
>>> on top of a compressed cluster, then there's no reason to forbid it.
>>
>> I'm not sure if
24.04.2020 20:44, Eric Blake wrote:
On 4/24/20 12:21 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
copy on write. The compressed data would remain untouched on disk but
some of the subcl
24.04.2020 20:56, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:44:33 PM CEST, Eric Blake wrote:
at the same time, I can see where you're coming from in stating that
if it makes management of extended L2 easier to allow zero subclusters
on top of a compressed cluster, then there's no reason to fo
On Fri 24 Apr 2020 08:25:45 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
>>> Reading the entire cluster will be interesting - you'll have to
>>> decompress the entire memory, then overwrite the zeroed portions.
>>
>> I don't think so, qcow2_get_host_offset() would detect the number of
>> contigu
On Fri 24 Apr 2020 08:15:04 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
> AFAIK, now compressed clusters can't be used in scenarios with guest,
> as qcow2 driver doesn't support rewriting them.
You can write to those images just fine, it's just not efficient because
you have to COW the compress
On 4/24/20 1:37 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 08:25:45 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
Reading the entire cluster will be interesting - you'll have to
decompress the entire memory, then overwrite the zeroed portions.
I don't think so, qcow2_get_host_offset() would
Our comment did not actually match the code. Rewrite the comment to
be less sensitive to any future changes to qcow2-bitmap.c that might
implement scenarios that we currently reject.
Signed-off-by: Eric Blake
Reviewed-by: Max Reitz
---
block/qcow2.c | 2 +-
1 file changed, 1 insertion(+), 1 de
In v3:
- patch 1: fix error returns [patchew, Max], R-b dropped
- patch 2,3: unchanged, so add R-b
Eric Blake (3):
block: Add blk_new_with_bs() helper
qcow2: Allow resize of images with internal snapshots
qcow2: Tweak comment about bitmaps vs. resize
include/sysemu/block-backend.h | 2 ++
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectif
There are several callers that need to create a new block backend from
an existing BDS; make the task slightly easier with a common helper
routine.
Suggested-by: Max Reitz
Signed-off-by: Eric Blake
---
include/sysemu/block-backend.h | 2 ++
block/block-backend.c | 23 +
On 3/17/20 1:16 PM, Alberto Garcia wrote:
The L2 bitmap needs to be updated after each write to indicate what
new subclusters are now allocated.
This needs to happen even if the cluster was already allocated and the
L2 entry was otherwise valid.
Signed-off-by: Alberto Garcia
Reviewed-by: Max R
24.04.2020 21:41, Alberto Garcia wrote:
On Fri 24 Apr 2020 08:15:04 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
AFAIK, now compressed clusters can't be used in scenarios with guest,
as qcow2 driver doesn't support rewriting them.
You can write to those images just fine, it's just not effici
51 matches
Mail list logo
