[pve-devel] [PATCH docs] qm: guest trim: add note mentioning issue with ext4
laurent at guerby.net
Fri Mar 10 10:43:46 CET 2023
On Fri, 2023-03-10 at 10:06 +0100, Fiona Ebner wrote:
> It is rather unexpected and seems worth mentioning. Reported in the
> community forum  and the explanation found by Alwin .
> : https://forum.proxmox.com/threads/123819/
> : https://serverfault.com/questions/1113127/fstrim-is-very-slow-
Here a workaround proposed by kernel developper when I reported the
"How to force EXT4_MB_GRP_CLEAR_TRIMMED on a live ext4?"
"My use case is having live migrated a virtual machine root disk from
one storage to another, the target supporting trim, but since fstrim in
the VM post migration does mostly nothing (assumes most space was
trimmed) I cannot release space to the new storage."
Meanwhile other than umount/mount, or actually writing to the dummy
you can try to use fallocate to allocate all the remaining space in the
file system and subsequently removing it. That should be more
but don't forget to sync after remove to make sure the space is
before you call fstrim."
I haven't followed up to see if code was added to deal with this
(tune2fs?) without using fallocate.
> Signed-off-by: Fiona Ebner <f.ebner at proxmox.com>
> qm.adoc | 6 ++++++
> 1 file changed, 6 insertions(+)
> diff --git a/qm.adoc b/qm.adoc
> index bd535a2..3ba2a3c 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -1063,6 +1063,12 @@ operations that have the potential to write
> out zeros to the storage:
> On a thin provisioned storage, this can help to free up unused
> +NOTE: There is a caveat with ext4 on Linux, because it uses an in-
> +optimization to avoid issuing duplicate TRIM requests. Since the
> guest doesn't
> +know about the change in the underlying storage, only the first
> guest-trim will
> +run as expected. Subsequent ones, until the next reboot, will only
> +parts of the filesystem that changed since then.
More information about the pve-devel