e created block device is known at the time of the
snapshot.
Regards
Zhiyong
On 1/9/23 9:57 PM, Kevin Wolf wrote:
Am 09.01.2023 um 13:45 hat Zhiyong Ye geschrieben:
Qemu provides powerful snapshot capabilities for different file
formats. But this is limited to the block backend being a file, and
Hi Kevin,
Can I ask again how base.img + diff.qcow2 can be re-merged into one
image via qemu-img or hmp command when modified.img is discarded?
Regards
Zhiyong
On 1/11/23 10:32 PM, Kevin Wolf wrote:
Am 11.01.2023 um 08:55 hat Zhiyong Ye geschrieben:
Hi Kevin,
Thank you for your reply and
Hi Kevin,
Thank you for your patience and explanations. I learned a lot from our
discussions and thank you again for your help.
Regards
Zhiyong
On 1/12/23 7:47 PM, Kevin Wolf wrote:
Am 11.01.2023 um 17:21 hat Zhiyong Ye geschrieben:
Hi Kevin,
Can I ask again how base.img + diff.qcow2 can
Hi Kevin,
Sorry to bother you again.
I intend to use this approach for snapshots of block devices, which, as
you say, requires a lot of disk space to store snapshot data. So, to
save disk space, after each successful external snapshot creation, I
want to shrink the block device that stores
Kevin Wolf wrote:
Am 21.02.2023 um 14:27 hat Zhiyong Ye geschrieben:
Hi Kevin,
Sorry to bother you again.
I intend to use this approach for snapshots of block devices, which, as you
say, requires a lot of disk space to store snapshot data. So, to save disk
space, after each successful externa
Hi Kevin,
Thank you for your patience and explanations.
Thanks again!
Zhiyong
On 2/23/23 7:39 PM, Kevin Wolf wrote:
Am 23.02.2023 um 08:35 hat Zhiyong Ye geschrieben:
Hi Kevin,
Thank you for your reply and this method works.
May I ask if this 'image-end-offset' field can be sh
Dear all,
Qemu provides powerful snapshot capabilities for different file formats.
But this is limited to the block backend being a file, and support is
not good enough when it is a block device. When creating snapshots based
on files, there is no need to specify the size of the snapshot image
xt. In fact,
commit e037c09c has also already elaborated on why we can't poll at
bdrv_do_drained_end().
Signed-off-by: Zhiyong Ye
---
block.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index be083f389e..ebbea72d64 100644
--- a/block.c
+++
On 7/19/21 6:24 PM, Kevin Wolf wrote:
Am 12.07.2021 um 07:38 hat Zhiyong Ye geschrieben:
When bdrv_set_aio_context_ignore() is called in the main loop to change
the AioContext onto the IO thread, the bdrv_drain_invoke_entry() never
gets to run and the IO thread hangs at co_schedule_bh_cb().
Th
xt. In fact,
commit e037c09c has also already elaborated on why we can't poll at
bdrv_do_drained_end().
Signed-off-by: Zhiyong Ye
---
block.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index be083f389e..ebbea72d64 100644
--- a/block.c
+++
xt. In fact,
commit e037c09c has also already elaborated on why we can't poll at
bdrv_do_drained_end().
Signed-off-by: Zhiyong Ye
---
block.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index be083f389e..ebbea72d64 100644
--- a/block.c
+++
xt. In fact,
commit e037c09c has also already elaborated on why we can't poll at
bdrv_do_drained_end().
Signed-off-by: Zhiyong Ye
---
block.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index be083f389e..ebbea72d64 100644
--- a/block.c
+++
thread, and the main thread poll in
bdrv_drained_end() waiting for the IO request to be drained, but the IO
thread cannot acquire the AioContext, which leads to deadlock.
Zhiyong Ye (1):
block: Do not poll in bdrv_set_aio_context_ignore() when acquiring new_context
block.c | 4 +++-
1 file
13 matches
Mail list logo
