Small thing to know about TRIM command (SSD)

more information about trim: [Bglug] [kwlug-disc] Installing onto an SSD

tl;dr: Queued Trim can have serious FS issues on SSDs since it's still not perfectly stable, and it's completely unnecessary if you put "fstrim" in a cron.daily or cron.weekly.

Not sure if @Thanatermesis knows about this or the configuration, just a heads up. :nod:

The trimming of the SSD's are managed by systemd since months, which should be better integrated with timers and to not shutdown the computer (probably) if the trimming is running

won't that mess up peopel switching to devuan?

Hi @TheTechRobo,
I've changed the topic, to point to the content.

In lamer terms I've understood the 'trim' as 'new way of defrag'. Because an flash storage could be really really fast, the decreasing speed will not really noticed over time. But it is there.

In my opinion the scheduled trim is a good thing. Maybe more useful in anachron, than cron. Only a few people will start the computer and imitatively shutdown. Even then, I'd think the shutdown will stall until the task is done. But I have not checked.

I am using a SD Card on my laptops for SSH keys, keepass database and all data nobody, except me, should have access to. At first the files weren't large and even a 64MB card wasn't full. I'm replacing the card every now and than, today the 512gb card is also full of special songs in mp3 of FLAC.
On the older (slower) cards (up to 95% full) I really see a improvement of speed after the use of trim. On the newest card (only 20% full) the effect is not noticeable.

So, it is important how fast the system is in the first place and the amount of stored data.
Since Elive is advertising to be used on older systems, I will vote for the trim command, even if the risk is there. Maybe we should have a way, to let the user update the blacklist? But as I understood your links there will be more drives unlisted as will listed new.