From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 437A291161 for ; Fri, 10 Mar 2023 12:00:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 24E7F1FD14 for ; Fri, 10 Mar 2023 11:59:52 +0100 (CET) Received: from 1.mo548.mail-out.ovh.net (1.mo548.mail-out.ovh.net [178.32.121.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 10 Mar 2023 11:59:51 +0100 (CET) Received: from mxplan7.mail.ovh.net (unknown [10.108.1.214]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 35392228BB for ; Fri, 10 Mar 2023 09:43:48 +0000 (UTC) Received: from guerby.net (37.59.142.108) by DAG3EX1.mxp7.local (172.16.2.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 10 Mar 2023 10:43:47 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-108S002bdb5d699-49d2-4974-8878-8ec0375fac2c, 1786B8461D8AA154A69B90876AACA4B25CC85070) smtp.auth=laurent@guerby.net X-OVh-ClientIp: 91.224.148.165 Message-ID: <1678441426.15922.17.camel@guerby.net> From: Laurent GUERBY To: Proxmox VE development discussion Date: Fri, 10 Mar 2023 10:43:46 +0100 In-Reply-To: <20230310090648.26873-1-f.ebner@proxmox.com> References: <20230310090648.26873-1-f.ebner@proxmox.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [37.59.142.108] X-ClientProxiedBy: DAG3EX1.mxp7.local (172.16.2.21) To DAG3EX1.mxp7.local (172.16.2.21) X-Ovh-Tracer-GUID: 5cda43fa-6b6c-4149-8dd8-6d923378461e X-Ovh-Tracer-Id: 18146128801442635287 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrvddukedgtdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefkuffhvfffjghftgfoggfgihesthekredtredtjeenucfhrhhomhepnfgruhhrvghnthcuifgfgfftuegjuceolhgruhhrvghnthesghhuvghrsgihrdhnvghtqeenucggtffrrghtthgvrhhnpeefvedtkeeijeetheelfefhkeeikeffvdetkeeftdejvdegkeeugfduheeitdelffenucffohhmrghinhepphhrohigmhhogidrtghomhdpshgvrhhvvghrfhgruhhlthdrtghomhdpkhgvrhhnvghlrdhorhhgnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeolhgruhhrvghnthesghhuvghrsgihrdhnvghtqedpnhgspghrtghpthhtohepuddprhgtphhtthhopehpvhgvqdguvghvvghlsehlihhsthhsrdhprhhogihmohigrdgtohhmpdfovfetjfhoshhtpehmohehgeekpdhmohguvgepshhmthhpohhuth X-SPAM-LEVEL: Spam detection results: 0 BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_NUMSUBJECT 0.5 Subject ends in numbers excluding current years RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH docs] qm: guest trim: add note mentioning issue with ext4 X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2023 11:00:22 -0000 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 [0] and the explanation found by Alwin [1]. > > [0]: https://forum.proxmox.com/threads/123819/ > [1]: https://serverfault.com/questions/1113127/fstrim-is-very-slow- > on-xfs-and-always-return-same-value-unlike-ext4/1113129#1113129 Hi, Here a workaround proposed by kernel developper when I reported the issue: https://lore.kernel.org/all/1634984680.26818.10.camel@guerby.net/ "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 files, you can try to use fallocate to allocate all the remaining space in the file system and subsequently removing it. That should be more efficient, but don't forget to sync after remove to make sure the space is released before you call fstrim." I haven't followed up to see if code was added to deal with this (tune2fs?) without using fallocate. Sincerely, Laurent > > Signed-off-by: Fiona Ebner > --- >  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 > space. >   > +NOTE: There is a caveat with ext4 on Linux, because it uses an in- > memory > +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 > consider > +parts of the filesystem that changed since then. > + >  Troubleshooting >  ^^^^^^^^^^^^^^^ >