We have moved to a new Sailfish OS Forum. Please start new discussions there.

Please install and use systemd's fstrim.timer

asked 2019-12-21 18:09:30 +0300

olf gravatar image

updated 2020-01-13 22:55:45 +0300

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.

Currently SailfishOS mounts only vFAT filesystems with the "direct discard" option, but for all other filesystems it never executes a discard / trim 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.

edit retag flag offensive close delete



Seems to work as well on my XA2. It took about a minute. On my JP1, it returns almost immediately, with not much trimmed. (I added -v parameter)

Fuzzillogic ( 2019-12-21 18:54:00 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-01-14 10:58:30 +0300

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2020-01-14 10:58:30 +0300

0xe4524ffe gravatar image

Fsrim timer can't be enabled by default for all devices. Even when emmc reports itself as trim-capable, running fstrim still results in a data corruption on some devices. So it should be enabled only after testing per device model.

Also, using trim reveals information about which blocks are in use and which are not(source).

And continuous trim(mounting with "discard" option) have been so problematic that it is disabled by default and not reccomended to use by many linux distributions(Debian, Arch, RedHat).

edit flag offensive delete publish link more



"Fsrim timer can't be enabled by default for all devices. Even when emmc reports itself as trim-capable, running fstrim still results in a data corruption on some devices. So it should be enabled only after testing per device model."

Can you please provide a source link or some own analysis for this bold statement, which contrasts to what most Linux distributions do.
Until then IMO there is no reason to believe that the eMMCs in devices supported by SailfishOS lie about their capabilities.

The remaining two paragraphs are definitely FUD:

  • Yes, on freshly TRIMmed FLASH one might (if discard zeros data) be able to detect which blocks are in use.
    So what, if you do not regard yourself as a potential victim of targeted attacks (e.g. by a secret service) and have everything encrypted (the filesystem reveals the same info much better)?
    Plus if you do believe that "they are after you", a regular Smartphone with SailfishOS (e.g., reflashed from Android) is definitely the wrong choice, anyway.
  • There is nothing "so problematic" about "direct discard", some distributions use it for FAT filesystems (e.g. SailfishOS).
    It just may be slow when utilising old FLASH-controllers with deficient firmwares.
  • All this is nicely described and thoroughly discussed in the links the OP provides: Reading often helps to prevent oneself from spreading FUD.
olf ( 2020-01-14 13:24:54 +0300 )edit

There are devices for which TRIM/queued TRIM is blacklisted, look in the libata-core in kernel source. Even though those are SSDs, emmcs may have the same problem, and there is too many of them to make blacklists. Sometimes problems are caused by faulty firmware, and considering the quality of firmware for mobile devices, there even more possibility that there are devices that corrupt data when you TRIM them.

I am not arguing that periodic trim shouldn't be enabled at all! But if there is a probability that it would corrupt data on some devices, maybe it's better to enable it per device model, after testing, to avoid that?

Well, the security argument is ridiculous in my opinion too, but it might be important for paranoid people. There is no point in encrypting a personal device at all IMHO.

SailfishOS 3.2.1 on XA2 Plus, none of the mounts have discard option. And it will be counterproductive if continuous trim will cause frequent freezes instead of speeding up flash memory io.

0xe4524ffe ( 2020-01-14 19:51:26 +0300 )edit

Basically agreed, except for that the eMMC firmwares are of concern, not device firmwares. There are actually less available eMMCs than SSD models, as eMMCs do not have such diversified supply chains. Why do you suspect their firmwares to be of inferior quality, albeit being developed and manufactured in a more coherent manner?

But these are exactly the documented (per each and every of the links in the OP) considerations:
"For how long do we continue to negatively affect speedandlifetime of the vast may of well behaving eMMCs and SD cards, in order to avoid mishaps with the few, old FLASH controllers, which incorrectly report their capabilitiesandhave a faulty Trim implementationandare not blacklisted?"

IMO, Jolla might check per fstrim -av on their officially supported devices and then deploy and enable fstrim.timer for all devices or a subset of these, depending on the outcome.
Already positively checked on Jolla 1s, Xperia X, XA2 and 10 and I never saw any reference to eMMCs misbehaving WRT Trim (in contrast to some SSDs > 5 years ago). Do you have one or is this just speculating?

P.S.: Well, this (enabling systemd's fstrim.timer) is not about "direct discards", anyways.
BTW, thanks for hinting that Jolla stopped mounting (v|ex)FAT with it. Just checked, Jolla stopped using the mount option "discard" when they switched from their sd-utils to udisks2 for mounting SD cards and USB-attached media in SFOS 2.2.0 (i.e., in 2018).

olf ( 2020-01-14 22:02:53 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2019-12-21 18:09:30 +0300

Seen: 849 times

Last updated: Jan 14 '20