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 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.
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?
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.
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).
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.
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.
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.
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.
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.
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?
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.
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.
