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
36 matches
Mail list logo
