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
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-
). 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
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
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
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
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
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
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
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
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
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
-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
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
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
: 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
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
/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
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/
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
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 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
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
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 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
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 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.
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
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
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
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 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 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
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
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
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&#
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
41 matches
Mail list logo
