Nieuw advies voor TRIM op SSD wegens systemd

[Pjotr]

In Ubuntu 16.04 en Linux Mint 18 zit de nieuwe systemd. Die vertoont soms kuren voor wat betreft opdrachtregels die je aan rc.local hebt toegevoegd. Bijvoorbeeld: een TRIM-opdrachtregel in rc.local voor een SSD, kan een minutenlange opstartvertraging veroorzaken.

Daarom heb ik mijn advies voor automatische TRIM herzien:
https://sites.google.com/site/computertip/ssd#TOC-Verouderde-methode-niet-langer-aangeraden-:-via-rc.local
(punt 8.1 en 8.2, linkerkolom)

Doe er je voordeel mee!   

[Ron]

Op advies m.b.t. moderne SSD schijven, heb ik fstrim niet in gebruik (Xubuntu 16.10)
In de terminal sudo fstrim -a -v ingevoerd, na 1 seconde kwam de melding, dat er 9GB was gedaan.
Is mijn systeem supersnel, of zie ik iets over het hoofd?

[h2o]

Systemd kan wel degelijk een rc.local uitvoeren hoor. Wel met wat aanpassingen. Kijk eens bij deze zoektocht:
https://www.google.nl/#newwindow=1&q=systemd+rc.local+replacement

Daar vind je een paar interessante varianten. Deze vind ik zelf de elegantste https://ask.fedoraproject.org/en/question/26898/what-is-the-auto-start-file-like-rclocal/

From http://joshua14.homelinux.org/blog/?p=1377

As root:

touch /etc/rc.local
chmod +x /etc/rc.local

Next, open the file for editing:-

vi /etc/rc.local

As this is basically a bash script itself, you need to include the bash interpreter as the first line of the file.

#!/bin/bash

You can now add whatever scripts or commands you like here – they will be run after everything else at your specific run-level has been started. In order for systemd to recognise and use this file, the systemd rc-local.service must be enabled.

systemctl enable rc-local.service

You can check the status of this service with:-

systemctl status rc-local.service

Dan hoef je je zelfgemaakte /etc/rc.local helemaal niet te veranderen.

[Pjotr]

@h2o: dat is mij bekend..... Maar in de praktijk werkt het niet lekker, althans niet met fstrim in rc.local.

Dat is tenminste mijn ervaring in Mint 18: de opstart werd maar liefst 1 minuut en 36 seconden vertraagd door rc-local.service, wanneer ik de fstrim-opdracht in rc.local had.

Diezelfde fstrim-opdracht in cron, via "sudo cron -e" en "@reboot /sbin/fstrim /” (waardoor fstrim ook wordt uitgevoerd bij opstart), veroorzaakte geen merkbare vertraging. Dus het ligt niet aan fstrim, maar aan systemd.

Je kunt de oorzaak van zo'n vertraging trouwens nauwkeurig opsporen in systemd, met de volgende opdracht:

Code: [Selecteer]

systemd-analyze critical-chain
Toevoegen aan cron voor elke opstart werkt dus, zoals gezegd, gewoon goed. Maar het is wat te ingewikkeld voor de meeste mensen, want je moet dan in de weer met Nano en zo. Het is simpeler, en in de praktijk bijna net zo goed, om het fstrim-script eenvoudigweg van de "weekly"-map naar de "daily"-map te schoppen. Vandaar dat dat ook mijn nieuwe advies is. 

[vanadium]

Dat is tenminste mijn ervaring in Mint 18: de opstart werd maar liefst 1 minuut en 36 seconden vertraagd door rc-local.service, wanneer ik de fstrim-opdracht in rc.local had.

Diezelfde fstrim-opdracht in cron, via "sudo cron -e" en "@reboot /sbin/fstrim /” (waardoor fstrim ook wordt uitgevoerd bij opstart), veroorzaakte geen merkbare vertraging. Dus het ligt niet aan fstrim, maar aan systemd.

Ik vermoed dat dit niet aan systemd op zich ligt. Commando's in rc.local worden één voor één uitgevoerd vooraleer het systeem verder doorstart. Commando's worden daarentegen via cron in de achtergrond opgestart: het systeem start onmiddellijk verder door terwijl het trim commando in de achtergrond loopt. Als je het commando in rc.local in de achtergrond opstart (met een & erachter), dan herwin je wellicht ook terug je snelle opstart.

Rest de vraag waarom je aanraad fstrim zo vaak uit te voeren. De handleiding van fstrim suggereert een week, en ik kan mij voorstellen dat dat bij normaal gebruik op een SSD die niet eivol is, voldoende moet zijn. Er zijn dan veel vrije blokken. De kans dat bij een nieuwe schrijfactie een gebruikt blok moet gerecupereerd worden, is dan klein.

[Pjotr]

Ik vermoed dat dit niet aan systemd op zich ligt. Commando's in rc.local worden één voor één uitgevoerd vooraleer het systeem verder doorstart. Commando's worden daarentegen via cron in de achtergrond opgestart: het systeem start onmiddellijk verder door terwijl het trim commando in de achtergrond loopt. Als je het commando in rc.local in de achtergrond opstart (met een & erachter), dan herwin je wellicht ook terug je snelle opstart.

Dat ga ik eens uitproberen. Dank voor de tip. 

Rest de vraag waarom je aanraad fstrim zo vaak uit te voeren. De handleiding van fstrim suggereert een week, en ik kan mij voorstellen dat dat bij normaal gebruik op een SSD die niet eivol is, voldoende moet zijn. Er zijn dan veel vrije blokken. De kans dat bij een nieuwe schrijfactie een gebruikt blok moet gerecupereerd worden, is dan klein.

SSD's zijn vaak behoorlijk klein, zeker in de populaire lagere prijsregionen..... Ruimtegebrek kan dus betrekkelijk snel gaan optreden.

Buitendien lijkt het me wellicht beter om vaak een kleine klus te doen, dan af en toe een grote klus. Minder verstorend voor de andere processen.... Liever vaak een beetje vertraging, dan af en toe veel vertraging.