On 5/12/25 13:16, Hanna Czenczek wrote:
On 16.04.25 09:16, Jean-Louis Dupond wrote:
To specify we use measure call for commit size calculations, we add a
new 'for_commit' option to the measure call.
This will be used in following commit to do a different measurement.
Why
On 5/12/25 14:28, Hanna Czenczek wrote:
On 29.04.25 12:31, Jean-Louis Dupond wrote:
When discard-no-unref is enabled, discards are not queued like it
should.
This was broken since discard-no-unref was added.
Add some helper function qcow2_discard_cluster which handles some common
checks and
discard-no-unref was enabled.
Jean-Louis Dupond (2):
qcow2: rename update_refcount_discard to queue_discard
qcow2: put discards in discard queue when discard-no-unref is enabled
block/qcow2-cluster.c | 16 ++--
block/qcow2-refcount.c | 25 +
block/qcow2.h
The function just queues discards, and doesn't do any refcount change.
So let's change the function name to align with its function.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-refcount.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/qcow2-re
.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-cluster.c | 16 ++--
block/qcow2-refcount.c | 17 +
block/qcow2.h | 4
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index ce8c0076b3
The function just queues discards, and doesn't do any refcount change.
So let's change the function name to align with its function.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-refcount.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/qcow2-re
discard-no-unref was enabled.
Jean-Louis Dupond (2):
qcow2: rename update_refcount_discard to queue_discard
qcow2: put discards in discard queue when discard-no-unref is enabled
block/qcow2-cluster.c | 16 ++--
block/qcow2-refcount.c | 25 +
block/qcow2.h
.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-cluster.c | 16 ++--
block/qcow2-refcount.c | 19 ++-
block/qcow2.h | 4
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index ce8c0076b3
=on:
required -> 13624475648
Commited image size: 13610385408
When calculating with discard-no-unref=off:
required -> 13520404480
Commited image size: 13504806912
Let me know if I made some mistakes :)
[1]: https://gitlab.com/qemu-project/qemu/-/issues/2369
Jean-Louis Dupond (3):
bloc
the blocks of the top and base
image, and if new blocks are needed, we increment the next_cluster_index
until everything is allocated for all blocks in the top image.
Then we have a new cluster_index, from where we can calculate the size
of the target image after commit.
Signed-off-by: Jean-Lo
his scenario is executed for discard-no-unref enabled and disabled.
Signed-off-by: Jean-Louis Dupond
---
tests/qemu-iotests/290 | 45
tests/qemu-iotests/290.out | 61 ++
2 files changed, 106 insertions(+)
diff --git a/tests/qemu-iote
To specify we use measure call for commit size calculations, we add a
new 'for_commit' option to the measure call.
This will be used in following commit to do a different measurement.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2.c| 16 +
inc
Hi,
I hope this patchset can get merged soon, as it contains some good
improvements.
Next to that, the change below only improves the performance on
discards? It's not that something is broken/can cause issues in the
current code?
Otherwise it might be a good idea to have this one merged as
e the destination size of the LV on a snapshot merge.
Thanks
Jean-Louis
On 2/17/25 16:34, Jean-Louis Dupond wrote:
Hi,
First of all sorry for the huge delay, but didn't had time to
follow-up on this lately.
And it got some lower priority, as we don't hit it often and have a
fairly easy w
On 7/10/24 15:00, Hanna Czenczek wrote:
On 05.06.24 15:25, Jean-Louis Dupond wrote:
When discard is not set to unmap/on, we should not allow setting
discard-no-unref.
Is this important? Technically, it’s an incompatible change, and
would require a deprecation warning first.
No it doesn&#
a Czenczek wrote:
On 05.06.24 15:25, Jean-Louis Dupond wrote:
When doing a measure on an image with a backing file and
discard-no-unref is enabled, the code should take this into account.
That doesn’t make sense to me. As far as I understand, 'measure' is
supposed to report how much
that this patch fix
kernel crash?
Best Regards,
Konstantin Kostiuk.
On Fri, Oct 25, 2024 at 1:06 PM Jean-Louis Dupond
wrote:
On 9/10/2024 10:34, Jean-Louis Dupond wrote:
> On 2/10/2024 12:06, Jean-Louis Dupond wrote:
>> The filesystem list in build_fs_mount_list sh
On 9/10/2024 10:34, Jean-Louis Dupond wrote:
On 2/10/2024 12:06, Jean-Louis Dupond wrote:
The filesystem list in build_fs_mount_list should skip bind mounts.
This because we end up in locking situations when doing fsFreeze. Like
mentioned in [1] and [2].
Next to that, the build_fs_mount_list
On 2/10/2024 12:06, Jean-Louis Dupond wrote:
The filesystem list in build_fs_mount_list should skip bind mounts.
This because we end up in locking situations when doing fsFreeze. Like
mentioned in [1] and [2].
Next to that, the build_fs_mount_list call did a fallback via
/d58847b497e212737007958c945af1df22a8ab58
Signed-off-by: Jean-Louis Dupond
---
qga/commands-linux.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/qga/commands-linux.c b/qga/commands-linux.c
index 51d5e3d927..426b040ab8 100644
--- a/qga/commands-linux.c
+++ b/qga/commands
When discard is not set to unmap/on, we should not allow setting
discard-no-unref.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index 50354e5b98..cead5479e4 100644
--- a/block/qcow2.c
+++ b/block/qcow2
: https://gitlab.com/qemu-project/qemu/-/issues/2369
Signed-off-by: Jean-Louis Dupond
---
block/qcow2.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 956128b409..50354e5b98 100644
--- a/block/qcow2.c
+++ b/block
On 5/06/2024 11:06, Jean-Louis Dupond wrote:
When doing a measure on an image with a backing file and
discard-no-unref is enabled, the code should take this into account.
If for example you have a snapshot image with a base, and you do a
discard within the snapshot, it will be ZERO and
When discard is not set to unmap/on, we should not allow setting
discard-no-unref.
Signed-off-by: Jean-Louis Dupond
---
block/qcow2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index 1ce7ebbab4..54c6b041b1 100644
--- a/block/qcow2.c
+++ b/block/qcow2
-Url: https://gitlab.com/qemu-project/qemu/-/issues/2369
Signed-off-by: Jean-Louis Dupond
---
block/qcow2.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 956128b409..1ce7ebbab4 100644
--- a/block/qco
On 16/04/2024 21:56, Andrey Drobyshev wrote:
On 10/27/23 14:10, Jean-Louis Dupond wrote:
[...]
I've checked all the code paths, and as far as I see it nowhere breaks
the discard_no_unref option.
It's important that we don't introduce new code paths that can make
holes in the q
On 20/10/2023 23:56, Andrey Drobyshev wrote:
This commit makes the discard operation work on the subcluster level
rather than cluster level. It introduces discard_l2_subclusters()
function and makes use of it in qcow2 discard implementation, much like
it's done with zero_in_l2_slice() / zero_l2_
On 27/10/2023 11:49, Hanna Czenczek wrote:
On 03.10.23 14:52, Jean-Louis Dupond wrote:
When the discard-no-unref flag is enabled, we keep the reference for
normal discard requests.
But when a discard is executed on a snapshot/qcow2 image with backing,
the discards are saved as zero clusters
On 25/09/2023 16:17, Hanna Czenczek wrote:
On 25.09.23 13:40, Jean-Louis Dupond wrote:
On 15/09/2023 13:21, Hanna Czenczek wrote:
On 05.09.23 15:08, Jean-Louis Dupond wrote:
When the discard-no-unref flag is enabled, we keep the reference for
normal discard requests.
But when a discard is
discard_in_l2_slice is called but zero_in_l2_slice. Which did not had
any logic to keep the reference when discard-no-unref is enabled.
Therefor we add logic in the zero_in_l2_slice call to keep the reference
on commit.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-off-by: Jean-Louis Dupond
On 15/09/2023 13:21, Hanna Czenczek wrote:
On 05.09.23 15:08, Jean-Louis Dupond wrote:
When the discard-no-unref flag is enabled, we keep the reference for
normal discard requests.
But when a discard is executed on a snapshot/qcow2 image with backing,
the discards are saved as zero clusters in
Replaced by PATCH v2.
On 4/09/2023 17:09, Jean-Louis Dupond wrote:
When the discard-no-unref flag is enabled, we keep the reference for
normal discard requests.
But when a discard is executed on a snapshot/qcow2 image with backing,
the discards are saved as zero clusters in the snapshot image
discard_in_l2_slice is called but zero_in_l2_slice. Which did not had
any logic to keep the reference when discard-no-unref is enabled.
Therefor we add logic in the zero_in_l2_slice call to keep the reference
on commit.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-off-by: Jean-Louis Dupond
this will just decrease the refcount but not
remove the reference itself. And it will also send the discard further
to the lower layer.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-cluster.c | 18 +++---
1 file changed, 7
On 2/06/2023 17:28, Hanna Czenczek wrote:
On 02.06.23 14:47, Jean-Louis Dupond wrote:
When we for example have a sparse qcow2 image and discard: unmap is
enabled,
there can be a lot of fragmentation in the image after some time.
Especially on VM's
that do a lot of writes/deletes.
zero, and, if
pass-discard-request is true, it is passed further down the stack.
The only difference is that the now-zero clusters are preallocated
instead of being unallocated.
This will avoid fragmentation on the qcow2 image.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-of
zero, and, if
pass-discard-request is true, it is passed further down the stack.
The only difference is that the now-zero clusters are preallocated
instead of being unallocated.
This will avoid fragmentation on the qcow2 image.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-of
On 31/05/2023 17:16, Hanna Czenczek wrote:
On 15.05.23 09:36, Jean-Louis Dupond wrote:
When we for example have a sparse qcow2 image and discard: unmap is
enabled,
there can be a lot of fragmentation in the image after some time.
Surely on VM's
that do a lot of writes/deletes.
This c
On 31/05/2023 17:05, Hanna Czenczek wrote:
On 15.05.23 09:36, Jean-Louis Dupond wrote:
When we for example have a sparse qcow2 image and discard: unmap is
enabled,
there can be a lot of fragmentation in the image after some time.
Surely on VM's
s/. Surely/, especially/
that do a l
On 26/05/2023 15:31, Hanna Czenczek wrote:
On 15.05.23 09:36, Jean-Louis Dupond wrote:
When we for example have a sparse qcow2 image and discard: unmap is
enabled,
there can be a lot of fragmentation in the image after some time.
Surely on VM's
that do a lot of writes/deletes.
This cause
Uploaded a new patch which might be better/cleaner :)
"[PATCH] qcow2: add discard-no-unref option"
That patch only applies to qcow2 and also passes unmap further down the
storage stack.
On 10/05/2023 16:27, Jean-Louis Dupond wrote:
When we for example have a sparse qcow2 image a
stack (if
discard:unmap is enabled).
This will avoid fragmentation and for example on a fully preallocated
qcow2 image, this will make sure the image is perfectly continuous.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-off-by: Jean-Louis Dupond
---
block/qcow2-cluster.c
on a discard request, but just zero them. This causes
the allocation the still exist, and results in no gaps.
This should also cause a perfectly continuous image when using full
preallocation.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621
Signed-off-by: Jean-L
). scripts/get_maintainer.pl can tell you who they are (including
their email addresses).
Check!
On 09.05.23 11:01, Jean-Louis Dupond wrote:
When we have a sparse qcow2 image and discard: unmap is enabled, there
is a lot of fragmentation in the image after some time. Surely on VM's
that do a l
Jean-Louis Dupond
---
block.c | 2 +
block/io.c | 2 +-
block/qcow2-cluster.c| 85 +++-
include/block/block-common.h | 1 +
qapi/block-core.json | 3 +-
qemu-
zilla.redhat.com/show_bug.cgi?id=1999141
Signed-off-by: Eduardo Habkost
Signed-off-by: Jean-Louis Dupond
Acked-by: Jason Wang
Acked-by: Jean-Louis Dupond
Reviewed-by: Cornelia Huck
---
hw/core/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/machin
zilla.redhat.com/show_bug.cgi?id=1999141
Signed-off-by: Eduardo Habkost
Signed-off-by: Jean-Louis Dupond
Acked-by: Jason Wang
Acked-by: Jean-Louis Dupond
Reviewed-by: Cornelia Huck
---
hw/core/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/machin
zilla.redhat.com/show_bug.cgi?id=1999141
Signed-off-by: Eduardo Habkost
Acked-by: Jason Wang
Acked-by: Jean-Louis Dupond
---
hw/core/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index e24e3e27db..b17a15508c 100644
--- a/h
On 1/11/2021 23:26, Michael S. Tsirkin wrote:
On Tue, Oct 12, 2021 at 10:24:28AM +0200, Jean-Louis Dupond wrote:
hw_compat modes only take into account their base name.
But if a device is created with (non)-transitional, then the compat
values are not used, causing migrating issues.
This
Hajnoczi wrote:
On Tue, Oct 12, 2021 at 10:36:01AM +0200, Jean-Louis Dupond wrote:
Forgot to CC maintainers.
Also CCing Jason Wang and Michael Tsirkin for VIRTIO.
Stefan
OMG
where all compat properties broken all the time?
Compat properties that existed when commit f6e501a28ef9 ("v
On 19/10/2021 17:27, Eduardo Habkost wrote:
On Tue, Oct 12, 2021 at 10:24:28AM +0200, Jean-Louis Dupond wrote:
hw_compat modes only take into account their base name.
What do you mean by "base name"?
virtio-net-pci (without the (non-)transitional extension.
But if a device is cr
Forgot to CC maintainers.
On 12/10/2021 10:24, Jean-Louis Dupond wrote:
hw_compat modes only take into account their base name.
But if a device is created with (non)-transitional, then the compat
values are not used, causing migrating issues.
This commit adds their (non)-transitional entries
hw_compat modes only take into account their base name.
But if a device is created with (non)-transitional, then the compat
values are not used, causing migrating issues.
This commit adds their (non)-transitional entries with the same settings
as the base entry.
Fixes https://bugzilla.redhat.com/
/show_bug.cgi?id=1999141
Signed-off-by: Jean-Louis Dupond
---
include/hw/qdev-core.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 4ff19c714b..5726825c2d 100644
--- a/include/hw/qdev-core.h
+++ b
54 matches
Mail list logo
