Reuse the new bdrv_co_write_req_prepare/finish helpers. The variation
here is that discard requests don't affect bs->wr_highest_offset, and it
cannot extend the image.
Signed-off-by: Fam Zheng
---
block/io.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
If we are growing the image and potentially using preallocation for the
new area, we need to make sure that no write requests are made to the
"preallocated" area which is [@old_size, @offset), not
[@offset, offset * 2 - @old_size).
Signed-off-by: Fam Zheng
Reviewed-by: Eric Blake
---
block/io.c
Truncation is the last to convert from open coded req handling to
reusing helpers. This time the permission check in prepare has to adapt
to the new caller: it checks a different permission bit, and doesn't
trigger the before write notifier.
Also, truncation should always trigger a bs->total_secto
As a mechanical refactoring patch, this is the first step towards
unified and more correct write code paths. This is helpful because
multiple BlockDriverState fields need to be updated after modifying
image data, and it's hard to maintain in multiple places such as copy
offload, discard and truncat
This brings the request handling logic inline with write and discard,
fixing write_gen, resize_cb, dirty bitmaps and image size refreshing.
The last of these issues broke iotest case 222, which is now fixed.
Signed-off-by: Fam Zheng
---
block/io.c | 22 +-
1 file changed, 9 i
Other I/O functions are already using a BdrvChild pointer in the API, so
make discard do the same. It makes it possible to initiate the same
permission checks before doing I/O, and much easier to share the
helper functions for this, which will be added and used by write,
truncate and copy range pat
A few trace points that can help reveal what is happening in a copy
offloading I/O path.
Signed-off-by: Fam Zheng
---
block/file-posix.c | 2 ++
block/io.c | 4
block/iscsi.c | 3 +++
block/trace-events | 6 ++
4 files changed, 15 insertions(+)
diff --git a/block/file-posi
Two problems exist when a write request that enlarges the image (i.e.
write beyond EOF) finishes:
1) parent is not notified about size change;
2) dirty bitmap is not resized although we try to set the dirty bits;
Fix them just like how bdrv_co_truncate works.
Reported-by: Kevin Wolf
Signed-off-
This matches the types used for bytes in the rest parts of block layer.
In the case of bdrv_co_truncate, new_bytes can be the image size which
probably doesn't fit in a 32 bit int.
Signed-off-by: Fam Zheng
---
block/io.c| 8 +---
include/block/block_int.h | 4 ++--
2 files ch
With in one module, trace points usually have a common prefix named
after the module name. paio_submit and paio_submit_co are the only two
trace points so far in the two file protocol drivers. As we are adding
more, having a common prefix here is better so that trace points can be
enabled with a gl
Based-on: 20180709163719.87107-1-vsement...@virtuozzo.com
v3: - Rebase onto Vladmir's:
[PATCH v5 0/4] fix image fleecing
on top of master, which has blklogwrites to be converted to BdrvChild for
the bdrv_co_pdiscard() parameter. [Kevin]
- Add file_ prefix to file protocol tr
Peter Krempa writes:
> On Fri, Jul 06, 2018 at 16:56:46 +0200, Kevin Wolf wrote:
>> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
>> > On Wed, 4 Jul 2018 17:14:02 +0100
>> > Peter Maydell wrote:
>> >
>> > > On 4 July 2018 at 14:34, Kevin Wolf wrote:
>> > > > Essentially, what is import
On Fri, 07/06 17:09, Eric Blake wrote:
> On 07/05/2018 02:37 AM, Fam Zheng wrote:
> > If we are growing the image and potentially using preallocation for the
> > new area, we need to make sure that no write requests are made to the
> > "preallocated" area which [@old_size, @offset), not [@offset, o
On Mon, 07/09 19:37, Vladimir Sementsov-Ogievskiy wrote:
> Fleecing scheme works as follows: we want a kind of temporary snapshot
> of active drive A. We create temporary image B, with B->backing = A.
> Then we start backup(sync=none) from A to B. From this point, B reads
> as point-in-time snapsho
On Mon, 07/09 19:37, Vladimir Sementsov-Ogievskiy wrote:
> Serialized writes should be used in copy-on-write of backup(sync=none)
> for image fleecing scheme.
>
> We need to change an assert in bdrv_aligned_pwritev, added in
> 28de2dcd88de. The assert may fail now, because call to
> wait_serialisi
On Mon, 07/09 19:37, Vladimir Sementsov-Ogievskiy wrote:
> Pass read flags and write flags separately. This is needed to handle
> coming BDRV_REQ_NO_SERIALISING clearly in following patches.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
On Mon, 07/09 19:37, Vladimir Sementsov-Ogievskiy wrote:
> Here two things are fixed:
>
> 1. Architecture
>
> On each recursion step, we go to the child of src or dst, only for one
> of them. So, it's wrong to create tracked requests for both on each
> step. It leads to tracked requests duplicati
On 07/02/2018 07:47 PM, John Snow wrote:
> I'm tracking the following series for Incremental Backup right now; if
> it's not on this list, I don't know about it:
>
> [Qemu-devel] [PATCH v4 0/2] block: formalize and test fleecing
Merged.
> [Qemu-devel] [PATCH v2 0/3] image fleecing
Dropped i
On 06/26/2018 09:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> This variable doesn't work as it should, because it is actually cleared
> in qcow2_co_invalidate_cache() by memset(). Drop it, as the following
> patch will introduce new behavior.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> -
On 06/28/2018 08:16 AM, Eric Blake wrote:
> On 06/26/2018 08:50 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> ---
>> block/qcow2.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/block/qcow2.c b/block/qcow2.c
>> in
On 06/26/2018 09:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20180705151515.779173-1-vsement...@virtuozzo.com
Signed-off-by: Max Reitz
---
qapi/block-core.json | 21 +++-
block/qcow2.h | 45 ++
blo
This new test verifies that VMDK backing file reads fail when the
backing file has a non-matching CID. This includes non-VMDK backing
files.
Signed-off-by: Max Reitz
Message-id: 20180702210721.4847-3-mre...@redhat.com
Signed-off-by: Max Reitz
---
tests/qemu-iotests/225 | 132 ++
VMDK performs a probing check in vmdk_co_create_opts() to prevent the
user from assigning non-VMDK files as a backing file, because it only
supports VMDK backing files. However, with the @backing runtime option,
it is possible to assign arbitrary nodes as backing nodes, regardless of
what the imag
From: Fam Zheng
Reported-by: Max Reitz
Signed-off-by: Fam Zheng
Message-id: 20180702025836.20957-5-f...@redhat.com
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
block/raw-format.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/raw-format.c b/block/raw-f
From: Fam Zheng
Reported-by: Max Reitz
Signed-off-by: Fam Zheng
Message-id: 20180702025836.20957-4-f...@redhat.com
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
block/qcow2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index d4ba0f781a..f32711
From: Fam Zheng
One of them is a typo. But update both to be more readable.
Reported-by: Kevin Wolf
Signed-off-by: Fam Zheng
Message-id: 20180702025836.20957-3-f...@redhat.com
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
block/file-posix.c | 2 +-
1 file changed, 1 insertion(+)
From: Fam Zheng
Reported-by: Max Reitz
Signed-off-by: Fam Zheng
Message-id: 20180702025836.20957-2-f...@redhat.com
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
block/qcow2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 33b61b7480..d4ba
The following changes since commit ec7eb2ae77cc207064e17ace048f7ec0c4b85d6f:
translate-all: honour CF_NOCACHE in tb_gen_code (2018-07-09 16:14:36 +0100)
are available in the Git repository at:
https://git.xanclic.moe/XanClic/qemu.git tags/pull-block-2018-07-09
for you to fetch changes up to
On Mon, Jul 9, 2018 at 8:06 PM Richard W.M. Jones wrote:
> On Mon, Jul 09, 2018 at 07:02:50PM +0200, Kevin Wolf wrote:
> > Am 09.07.2018 um 18:52 hat Richard W.M. Jones geschrieben:
> > > On Mon, Jul 09, 2018 at 07:38:05PM +0300, Nir Soffer wrote:
> > > > We are discussing importing VM images to
On Mon, Jul 09, 2018 at 07:02:50PM +0200, Kevin Wolf wrote:
> Am 09.07.2018 um 18:52 hat Richard W.M. Jones geschrieben:
> > On Mon, Jul 09, 2018 at 07:38:05PM +0300, Nir Soffer wrote:
> > > We are discussing importing VM images to KubVirt. The goal is to be
> > > able to import an existing qcow2 d
On 28.06.2018 01:29, Laurent Vivier wrote:
> Co-developed-by: Mark Cave-Ayland
> Signed-off-by: Mark Cave-Ayland
> Signed-off-by: Laurent Vivier
> ---
[...]
> diff --git a/hw/display/macfb-template.h b/hw/display/macfb-template.h
> new file mode 100644
> index 00..b6ae5d728f
> --- /dev/n
Am 09.07.2018 um 18:52 hat Richard W.M. Jones geschrieben:
> On Mon, Jul 09, 2018 at 07:38:05PM +0300, Nir Soffer wrote:
> > We are discussing importing VM images to KubVirt. The goal is to be
> > able to import an existing qcow2 disk, probably some appliance stored
> > on http server, and and conv
On Mon, Jul 09, 2018 at 05:52:42PM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 09, 2018 at 07:38:05PM +0300, Nir Soffer wrote:
> > We are discussing importing VM images to KubVirt. The goal is to be
> > able to import an existing qcow2 disk, probably some appliance stored
> > on http server, and
Am 09.07.2018 um 18:38 hat Nir Soffer geschrieben:
> We are discussing importing VM images to KubVirt. The goal is to be
> able to import an existing qcow2 disk, probably some appliance stored
> on http server, and and convert it to raw format for writing to storage.
>
> This can be also useful fo
On Mon, Jul 09, 2018 at 07:38:05PM +0300, Nir Soffer wrote:
> We are discussing importing VM images to KubVirt. The goal is to be
> able to import an existing qcow2 disk, probably some appliance stored
> on http server, and and convert it to raw format for writing to storage.
>
> This can be also
Hi all.
This fixes image fleecing scheme for 3.0, details are in 04 patch.
01 is a significant fix too.
v5: - keep one _internal recursive function like in original code [Fam]
- grammar and rewording [Eric] (a bit changed,
be free to fix/reword in flight)
Serialized writes should be used in copy-on-write of backup(sync=none)
for image fleecing scheme.
We need to change an assert in bdrv_aligned_pwritev, added in
28de2dcd88de. The assert may fail now, because call to
wait_serialising_requests here may become first call to it for this
request with se
We are discussing importing VM images to KubVirt. The goal is to be
able to import an existing qcow2 disk, probably some appliance stored
on http server, and and convert it to raw format for writing to storage.
This can be also useful for for oVirt for importing OVA, since we like to
pack
disks in
Fleecing scheme works as follows: we want a kind of temporary snapshot
of active drive A. We create temporary image B, with B->backing = A.
Then we start backup(sync=none) from A to B. From this point, B reads
as point-in-time snapshot of A (A continues to be active drive,
accepting guest IO).
Thi
Here two things are fixed:
1. Architecture
On each recursion step, we go to the child of src or dst, only for one
of them. So, it's wrong to create tracked requests for both on each
step. It leads to tracked requests duplication.
2. Wait for serializing requests on write path independently of
Pass read flags and write flags separately. This is needed to handle
coming BDRV_REQ_NO_SERIALISING clearly in following patches.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block.h | 3 ++-
include/block/block_int.h | 14 +
include/sysemu/block-backe
07.07.2018 00:46, Eric Blake wrote:
On 07/06/2018 04:32 PM, Eric Blake wrote:
On 07/05/2018 02:46 AM, Vladimir Sementsov-Ogievskiy wrote:
Before commit 9ded4a01149 "backup: Use copy offloading",
BDRV_REQ_NO_SERIALISING was used for only one case: read in
copy-on-write operation during backup. A
07.07.2018 00:32, Eric Blake wrote:
On 07/05/2018 02:46 AM, Vladimir Sementsov-Ogievskiy wrote:
Before commit 9ded4a01149 "backup: Use copy offloading",
BDRV_REQ_NO_SERIALISING was used for only one case: read in
copy-on-write operation during backup. Also, the flag was handled only
on read path
On 2018-07-05 17:15, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
> If it appropriate for 3.0, let's push it. If not - then for 3.1
> with fixed "since". Should I cc stable?
>
> v4: - fix indentation
>
> v3: - update Qcow2OverlapCheckFlags in qapi/bl
On 2018-07-02 23:07, Max Reitz wrote:
> The VMDK driver assumes that its backing file is always a VMDK file,
> too, because it verifies that when creating the overlay. However, that
> verification means nothing at runtime, and consequently you can assign
> non-VMDK backing files to a VMDK node. T
On Mon, 07/09 17:38, Vladimir Sementsov-Ogievskiy wrote:
> 09.07.2018 16:17, Fam Zheng wrote:
> > On Mon, 07/09 12:43, Vladimir Sementsov-Ogievskiy wrote:
> > > 09.07.2018 04:15, Fam Zheng wrote:
> > > > On Fri, 07/06 21:30, Vladimir Sementsov-Ogievskiy wrote:
> > > > > Here two things are fixed:
>
Would there be a chance of getting this included in 3.0?
On 07/06/2018 03:00 PM, Ari Sundholm wrote:
The sector size needs to be large enough to accommodate the data
structures for the log super block and log write entries. This was
previously not properly checked, which made it possible to caus
09.07.2018 16:17, Fam Zheng wrote:
On Mon, 07/09 12:43, Vladimir Sementsov-Ogievskiy wrote:
09.07.2018 04:15, Fam Zheng wrote:
On Fri, 07/06 21:30, Vladimir Sementsov-Ogievskiy wrote:
Here two things are fixed:
1. Architecture
On each recursion step, we go to the child of src or dst, only fo
Hi,
I recently noticed that iotest 147 was hanging on my laptop, but worked
fine on my s390x LPAR. Turned out that the architecture was a red
herring; on both platforms, things fail with the 'simple' trace backend
and work with e.g. the 'log' trace backend. Some details on the
failures with the 's
On Mon, 07/09 12:43, Vladimir Sementsov-Ogievskiy wrote:
> 09.07.2018 04:15, Fam Zheng wrote:
> > On Fri, 07/06 21:30, Vladimir Sementsov-Ogievskiy wrote:
> > > Here two things are fixed:
> > >
> > > 1. Architecture
> > >
> > > On each recursion step, we go to the child of src or dst, only for on
On Mon, 9 Jul 2018 08:58:05 +0200
Thomas Huth wrote:
> On 06.07.2018 13:11, Cornelia Huck wrote:
> > On Wed, 4 Jul 2018 17:14:02 +0100
> > Peter Maydell wrote:
> >
> >> On 4 July 2018 at 14:34, Kevin Wolf wrote:
> >>> Essentially, what is important to me isn't getting these options dropped
On Mon, Jul 09, 2018 at 01:08:38PM +0200, Cornelia Huck wrote:
> On Mon, 09 Jul 2018 08:33:05 +0200
> Markus Armbruster wrote:
>
> > Peter Maydell writes:
> >
> > > On 6 July 2018 at 15:56, Kevin Wolf wrote:
> > >> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
> > >>> That way, we
On Mon, 09 Jul 2018 08:33:05 +0200
Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 6 July 2018 at 15:56, Kevin Wolf wrote:
> >> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
> >>> That way, we can still easily remove old cruft (case (a)), but still
> >>> accommodate cases
09.07.2018 04:15, Fam Zheng wrote:
On Fri, 07/06 21:30, Vladimir Sementsov-Ogievskiy wrote:
Here two things are fixed:
1. Architecture
On each recursion step, we go to the child of src or dst, only for one
of them. So, it's wrong to create tracked requests for both on each
step. It leads to tr
Am 06.07.2018 um 23:20 hat Eric Blake geschrieben:
> On 07/06/2018 11:45 AM, Kevin Wolf wrote:
> > If the virtual disk size isn't aligned to full clusters,
> > bdrv_co_do_copy_on_readv() may get pnum == 0 before having the full
> > cluster completed, which will let it run into an assertion failure:
On Fri, Jul 06, 2018 at 16:56:46 +0200, Kevin Wolf wrote:
> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
> > On Wed, 4 Jul 2018 17:14:02 +0100
> > Peter Maydell wrote:
> >
> > > On 4 July 2018 at 14:34, Kevin Wolf wrote:
> > > > Essentially, what is important to me isn't getting these o
57 matches
Mail list logo
