From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 0BA8B1FF13B for ; Wed, 25 Mar 2026 09:22:17 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A59D7B3F2; Wed, 25 Mar 2026 09:22:37 +0100 (CET) Message-ID: <66706ce3-ba66-4acb-b9d1-677071978040@proxmox.com> Date: Wed, 25 Mar 2026 09:22:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC proxmox{,-backup} 0/6] add scheduled fstrim job for datastore's backing filesystems To: Thomas Lamprecht , pbs-devel@lists.proxmox.com References: <20260319143649.681937-1-c.ebner@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1774426876237 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: C6EHBGEUWZXEI25K7DQFAMSCJZHOO7VX X-Message-ID-Hash: C6EHBGEUWZXEI25K7DQFAMSCJZHOO7VX X-MailFrom: c.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 3/25/26 8:08 AM, Thomas Lamprecht wrote: > Am 19.03.26 um 15:37 schrieb Christian Ebner: >> As reported in the community forum [0], the default systemd service >> to run fstrim does not cover datastores mounted via systemd mount >> unit, since the fstrim command is invoked via: >> ``` >> fstrim --listed-in /etc/fstab:/proc/self/mountinfo ... >> ``` >> which however only considers the list up to the first non-empty >> file according to the man page [1]. > > But basically that means systemd would already be totally fine with > fstrim'ing all mounted file-systems, not sure if its really worth to > reimplement this ourselves, especially given that a single datastore > doesn't exactly map to one filesystem. Also, ZFS, a popular choice for > datastores, comes with it's own trim handling triggering every first > Sunday of a month (see /etc/cron.d/zfsutils-linux). The initial idea was to simply drop the /etc/fstab part in an override and therefore trim all mounted filesystems. There were however valid concerns for doing that in case of e.g. co-installations of PBS with PVE. > I'd rather prefer leveraging what's existing compared to carry our own > implementation here, not just for the (probably not *that* big) > maintenance burden, but also because it increases complexity in general > by re-implementing parts of systemd ourselves (can be fine, if there's > a good reason, I'm not yet convinced that this is one). > > I'd rather hook into fstrim.service/timer (e.g. through an override that > can add another ExecStart). If it turns out that this is so frequently > in need for per-datastore configuration with good use cases where such > an approach really falls short, we can still provide actual integration > into api/ui/... and OTOH, we cannot easily drop such an integration like > here again. Okay, then let's go down this route: So if I understand your suggestion correctly, you would simply write or append the systemd overwrite on datastore creation, identifying the underlying filesystem and adding the additional fstrim command invocation for this datastore backing filesystem? ZFS filesystems excluded, that is... >> To allow for easy configuration of scheduled fstrims also on >> filesystems backing datastores in PBS, implement a scheduled job >> with per-datastore schedule configuration. Enable and default to >> executing the fstrim job for new datastores (except crated via ZFS >> dialog). >> >> Open question remaining: >> How to best handle datastores located on ZFS? Should the command default >> to zpool trim? Should it set `autotrim=on` on datastore creation instead >> and silently ignore as it is now? > > see above, it's already handled. I see, thanks for pointing this out!