Install and use systemd's fstrim.timer

Feature Requests
#1

This feature suggestion was filed in December 2019 at TJC, and was discussed among community members in January 2020, basically reaching consensus that this makes sense to be deployed (for details see the original thread at TJC): Please install and use systemd’s fstrim.timer

Because Together.Jolla.com has been put into read-only state more than a year after this initial conversation about this feature suggestion, and the promised transfer of content from TJC to this forum never materialised, this feature suggestion has to be re-filed here to be able to track and discuss it any further.

I still would appreciate any feedback by sailors on the content of this feature suggestion.
I also do not have the impression that this topic was ever considered at Jolla, at least I have not found anything mentioned anywhere in this regard at TJC or FSO besides my post.

P.S.: Cut & Paste of the core content of this feature suggestion.

Please install and use systemd’s fstrim.timer

asked Dec 21 2019

olf gravatar image

olf
10393 ●104 ●201 ●158

updated Jan 13 2020

Dear sailors,

please install and use systemd’s fstrim.timer to regularly (e.g. weekly) trigger a “block discard” (“trim”) on FLASH media which supports it.

In the past (long ago) SailfishOS mounted (only) vFAT filesystems with the “direct discard” option, but now it never executes a discard / trim for all filesystems AFAICS.

Performing a fstrim -a manually is working fine on SailfishOS since at least v2.2.0, even on encrypted partitions (their “trim” capability can be easily checked manually per lsblk -D ); tested on Jolla 1 and Xperia X.

HTH & happy sailing!

P.S.: … and the outcome for Fedora is “[Phoronix] Fedora 32 Greenlit For Enabling FSTRIM Support By Default”, which is what most other Linux distributions already implement.

5 Likes
Migrating Sailfish OS git repos to Github
Community meeting on IRC 8th December 2022
#2

Would something like this implement that?

Builds a new util-linux-systemd-fstrim subpackage containing the service and timer files.

(Also I have taken the liberty to move this topic into the Feature Requests category)

3 Likes
#3

Yes.
This is looking good, AFAICS: Primarily I read the spec file changes, though your use of the build infrastructure (OBS & for chum) also looks really fine.

Have you tested the generated package, if it installs and works (i.e., trims regularly) as intended?

#4

I have not tested those particular binaries. But I have tried the .service/.timer and they do what they are supposed to.

Installation works fine, it enables but doesn’t start the timer though. Not sure what the right incantation in %post is to do that.
Reboot helps and timer is started correctly.
Uninstallation is also fine.

#5

I have done a rebuild with relaxed dependencies so just the package can be installed without requiring the rebuilt binary package .

So test away! :slight_smile:

2 Likes
#6

But the principal question remains (as with most suggestions / feature requests), even though all technical work is done:
How do we get Jolla’s attention directed at this?

I know, putting this on the list for an “IRC community meeting”, attending it and proposing this there would be a way (but not for me, personally), but that usually results in no specific feedback, anyway.
Furthermore, I would rather keep the discussion (with sailors) here (where it belongs, IMO, plus where the context is).

1 Like
#7

@olf - I would expect fstrim to be enabled for storage. Maybe should classify this as a bug.

This forum was expected to be communication channel with Jolla developers, so let’s see if it gets picked up as it should.

1 Like
#8

I think a pull request would be the proper way forward.

I’m not planning to do that, but anyone obviously is welcome to take my changes above and make one. It is simple enough really.

#9

Well, that is what I originally did (for exactly that reason: more likely to catch a sailor’s attention when filed as a bug, plus it really is “half a bug, half a feature request” IMO), but @nephros had a different opinion and changed it to be a feature request.

I am more than tired of applying the “let’s see if it gets picked up as it should” method, which often works fine elsewhere, but almost never WRT Jolla (i.e., at FSO, TJC, git.sailfishos.org etc.), but in the end it is up to them to continue ignoring most contributions (or change their ways and at least leave a comment). Mind that this bug / feature suggestion is already almost 2 years old, and never received any attention from a sailor.
Well, the only thing I can do is to document that clearly.

2 Likes
#10

Done: https://github.com/sailfishos/util-linux/pull/2
Update (2021-09-06): After a single substancial change request (Requires: xyz-devel → Requires: pkgconf(xyz)) and multiple nitpicking and partially inconsistent (compared to the extant code) change requests in a row, I refiled the MR as https://github.com/sailfishos/util-linux/pull/3
Seems to be in “Jolla state” since then: Stalled with no feedback.

P.S.: @nephros, thank you very much for implementing this, plus creating an easily testable package, and your general support WRT this bug / feature request.

3 Likes
#11

Moving this issue and thread (“topic”) back to the category Bug Reports, as suggested by @rinigus, so it may more likely be “picked up as it should”, either by sailors or the community bug hunter team.

2 Likes
#12

I guess we have the weird situation now that this is all of:

  • a feature request
  • a bug report
  • a pull request

With the current structuring/agenda of the community meetings, I guess the way forward with them most chances of getting feedback is to use the new “pending pull requests” topic of IRC meetings.

3 Likes
#13

Making use of the new “tracked” tag in the section, I’ve moved this back to Feature Requests, created an internal issue for it and tagged it here as “tracked”.

There should be no difference in terms of “internal” visibility, and I think this is more accurately classified as a feature request rather than a bug.

I’ve also added your PR to the issue @olf. I’m sorry that the change seems to have stalled for so long now; I’ll raise it internally and see if we can at least get some decision one way or another on it.

2 Likes
#14

Even though this may appear to be a typical feature request (as it currently “works” without it), I do concur with rinigus’ statement to “expect fstrim to be enabled”, because Fedora was one of the last major Linux distribution to do so in 2019 (IIRC Canonical / Ubuntu and SUSE enabled it before that).

Speaking as an electrical engineer with experience in VLSI circuit design (EDA / “chip design”) and embedded software (here: the wear-leveling algorithms of modern FLASH memory controllers), not running any kind of “trim” / “discard” regularly (i.e., asynchronously; or synchronously, as Jolla did mount vFAT for years) constitutes rather a bug than a feature request.

TL;DR:

I do not mind at all if this becomes implemented by the merge request @nephros designed and I posed, or by other means, but on technical grounds this ought to be implemented somehow.

P.S.:

IMHO there is no reason for you to feel sorry:
● It wasn’t you.
● You are the one ultimately addressing the cruft accumulated over years:
    I appreciate this a lot!
BTW, does “seems” indicate that the view from the outside provided the false impression that this has been stalled for three years, while sailors have been working on this? :wink:

6 Likes
#15

On my Xperia 10 III (Sailfish OS 4.4.0.72), it seems fstrim is not supported on the encrypted partition:

[root@Xperia10III defaultuser]# fstrim /home
fstrim: /home: the discard operation is not supported

[root@Xperia10III defaultuser]# lsblk --discard /dev/sda79
NAME                                          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda79                                                0        4K      32G         0
├─sailfish-root                                      0        4K      32G         0
└─sailfish-home                                      0        4K      32G         0
  └─luks-f3ab783e-b5e9-4345-bfc2-45d6361baf91        0        0B       0B         0

Maybe something has changed since the original post 3 years ago?
If this is the case, it’s not only a matter of enabling the fstrim.timer, but support for TRIM passthrough for the LUKS partition would also need to be enabled.

2 Likes
#16

That is not really true: If something does not support discards, fstrim simply does not “trim” it. Hence this is no reason not to care about this topic.

But you are sure correct, that enabling fstrim.timer does not trim anything on the /home volume in this state.

Because it was working fine for years (tested regularly on SFOS 2.2.0 to 3.2.1), I assume it is just some configuration change, which broke it.