SSD wöchentliches TRIM per fstrim.timer

[josef-wien]

Keine Ahnung, warum die Blacklist dort fehlt.

queued TRIM wird erst seit Kernel 3.12 unterstützt.

Erstaunlich, dass es u.a. die relativ neue Samsung SSD 850 PRO auch in die Liste geschafft hat.

Wie es aktuell aussieht, sind auch andere Samsung-SSD betroffen: http://www.spinics.net/lists/linux-ide/msg50730.html

 

[Boreas]

@josef-wien,
Richtig, das ist vollkommen überflüssig - das Skript könnte problemlos in after.local geschrieben werden. Und ja, natürlich erreicht man das Gleiche vielleicht/wahrscheinlich
besser mit einem cron-Job - für ein einmalig beim Booten zu startenden Job mit @reboot in der crontab-Datei. Aber wie unter #11 gesagt ging es mir darum nicht.
Ich habe das im Wesentlichen für mich als Übung verstanden.

Zu SUSEs fstrim.service stellt sich die Frage der zeitlichen Abarbeitung. In fstrim.timer ist hier unter Abschnitt [Timer]

OnCalendar=weekly
AccuracySec=1h
Persistent=true

vorgegeben. Wenn ich das richtig lese, bedeutet dass: Der Trimbefehl wird wöchentlich und dann innerhalb eines Zeitfensters von 1 Stunde ausgeführt.
Wenn der Rechner aber gerade in dieser Zeit nicht läuft, fällt die Aktion in diesem Wochenzyklus aus (ich halte das nicht für besonders glücklich, da
die Woche jeweils um 24:00 (0:00) abläuft.

 

[Anonymous]

Und was ist mit

Persistent=true

? :???:

 

[Boreas]

Guter Hinweis, unter

man systemd.timer

findet sich bei mir nichts dazu - aber unter http://www.freedesktop.org/software/systemd/man/systemd.timer.html wird Persistent erläutert.
Ich würde das bezogen auf fstrim.service so beschreiben: Boolesches Argument. Bei true, wird der Zeitpunkt des letzten Auslösens von fstrim.service gespeichert. Wenn der Zeitgeber aktiviert ist,
wird fstrim.service sofort ausgelöst sofern der Dienst hätte ausgeführt werden müssen in der Zeit, in der der Zeitgeber nicht aktiviert war.
Dies ist hilfreich, da in diesem Fall ein verpasster und jetzt überfälliger Dienst nachgeholt wird. Persistent findet nur in Verbindung mit dem Argument OnCalendar bei der
Timerkonfiguration Berücksichtigung.
Wenn ich das jetzt richtig verstehe, kann die openSUSE Implementierung des Dienstes fstrim.service sehr gut übernommen werden - oder?

 

[Anonymous]

Wenn ich das jetzt richtig verstehe, kann die openSUSE Implementierung des Dienstes fstrim.service sehr gut übernommen werden - oder?

Auch für openSUSE 13.1? Deswegen dieser Thread.

 

[Boreas]

@LUH 3417,
ich denke ja - dazu müssen nur die systemd-Services wie unter 13.2 erstellt / aktiviert werden, die in 13.2 verwendet werden. Wenn Du geduldig bist, versuch ich das einmal auf einer Testmaschine mit 13.1 installiert. Ich bin aber nur ein normaler Nutzer und keiner von den Profis hier im Forum. Wird mich aber interessieren, ob so etwas machbar ist

 

[Anonymous]

Klar habe ich Geduld. Seit 2 Wochen läuft bei mir erst mal das Ubuntu-Script in /etc/cron.weekly/.

Kann man irgendwie herausfinden ob ein Notebook oder PC die queued TRIM commands überhaupt hat?
Auch wenn das erst ab Kernel 3.12 unterstützt wird, so muss man sich dann beim SSD-Kauf deswegen keine Sorgen machen.

 

[josef-wien]

queued TRIM ist eine Funktionalität von SSD und Betriebssystem. An welchem PC die SSD angeschlossen ist, spielt überhaupt nicht mit.

 

[Anonymous]

queued TRIM ist eine Funktionalität von SSD und Betriebssystem. An welchem PC die SSD angeschlossen ist, spielt überhaupt nicht mit.

Das verstehe ich nun gar nicht mehr. Du hattest doch geschrieben:

Ergänzung: Die Probleme bei einigen Micron/Crucial-SSD sowie der Samsung 850 PRO-SSD betreffen nur das mit der ATA-Spezifikation 3.1 zusätzlich eingeführte queued TRIM (die ursprünglichen, als non-queueable definierten Anweisungen funktionieren auch bei diesen SSD).

Es gibt doch auch alte PCs mit SATA-II / Serial ATA 3,0 Gbit/s, SATA Revision 2.x.
A drawback of the original ATA TRIM command is that it was defined as a non-queueable command and therefore could not easily be mixed with a normal workload of queued read and write operations. SATA 3.1 introduced a queued TRIM command to remedy this.
(so kopiert von Wikipedia: Trim (computing) - Hardware support)

Wie ist das zu verstehen? Abwärtskompatibel?

 

[josef-wien]

In diese Tiefen bin ich nicht vorgedrungen, daher kann ich nicht sagen, ob "alte" Controller hemmend eingreifen, obwohl Betriebssystem und SSD queued TRIM unterstützen. Einerseits geht es den Controller nichts an, welche Anforderungen vom Betriebssystem an die SSD übermittelt werden. Andererseits können sich die drei auch auf den reduzierten Befehlssatz der niedrigsten Version einigen.

 

[Anonymous]

Danke für die Info.
Ich habe ja openSUSE 13.1 mit Kernel 3.11 und irgendwann kommt bestimmt ein Firmwareupdate für die Samsung SSD 840 EVO im Fall dass die wirklich ein Bug im queued TRIM haben.

 

[josef-wien]

Samsung hat den Fehler für die 840 EVO übrigens erst im April mit der firmware EXT0DB6Q eingeführt. Deine Version sollte Dir

/sbin/udevadm info -p $(/sbin/udevadm info -q path -n /dev/sda) | grep ID_REVISION

zeigen.

 

[Anonymous]

Samsung hat den Fehler für die 840 EVO übrigens erst im April mit der firmware EXT0DB6Q eingeführt.

Ich bin sprachlos! Mit dem Update sollte die Leseleistung verbessert werden.
Aber bei mir läufts ja. Mit dem Kernel 3.11. Gibt es dieses Problem eigentlich nur unter Linux?

 

[josef-wien]

Ein Betriebssystem, das noch nie etwas von queued TRIM gehört hat, kann keine diesbezüglichen Fehler einer SSD-firmware ans Tageslicht bringen.

 

[Anonymous]

Ein Betriebssystem, das noch nie etwas von queued TRIM gehört hat, kann keine diesbezüglichen Fehler einer SSD-firmware ans Tageslicht bringen.

Danke. Gut zu wissen!

Darf ich dich noch was fragen:

Wie mache ich TRIM wenn ich Clonezilla vom USB-Stick starte und ein paar Dateien anlege und lösche?
Muss ich die ext4-Partition auf der SSD dann immer mit -o discard mounten? Oder genügt die TRIM-Funktion 1× wöchentlich in openSUSE?

 

[josef-wien]

fstrim analysiert das Dateisystem und meldet die Adressen aller *) Sektoren, die das Dateisystem zu diesem Zeitpunkt als "frei" betrachtet, an die SSD. Somit:

genügt die TRIM-Funktion ... in openSUSE

*) sofern keine einschränkenden Parameter verwendet werden

 

[Boreas]

So hat zwar etwas gedauert aber hier nun mein Ergebnis:
Zunächst die Versionsstände von systemd:

openSUSE 13.1, mit systemd, Version 208-35.1
openSUSE 13.2, mit systemd, Version 210-25.16.1

Unabhängig davon noch ein Hinweis zu Post #1

Hallo Leute!
...
Man muss ihn so aktivieren:

systemctl enable fstrim.service
systemctl start fstrim.service

...

sollte eigentlich nicht funktionieren. Man bekommt da folgende Fehlermeldung

The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

Gelöst bekommt man das mit Hilfe von 3), denn der Dienst wird über einen Timer gestartet, in diesem Fall ja über fstrim.timer.
Zurück zur eigentlichen Frage. Den trim-Service, der bei 13.2 angeboten wird, kann so nicht unter 13.1 funktionieren. Der Grund
ist, systemd (und) dessen Abhängigkeiten gestatten, bei dem obigen Versionsstand nicht die Umsetzung. Es sind konkret die Parameter

AccuracySec=1h
Persistent=true

in der Section [Timer], die nicht erkannt werden. Dies sind aber gerade diejenigen, die ein wöchentliches trim garantieren, insbesondere
wenn der Rechner nicht permanent läuft. Ich weiß nicht inwiefern ein Update auf Version 220 möglich ist - in den offiziellen Paketquellen habe ich nichts gefunden.
Interessant und für mich unverständlich ist, dass unter 13.2 der Parameter

Persistent=true

ebenfalls unbekannt ist. Die Fehlermeldung nach folgendem Befehl

systemctl enable fstrim.timer

lautet:

May 29 00:20:57 linux-xdse.site systemd[1]: [/usr/lib/systemd/system/fstrim.timer:8] Unknown lvalue 'Persistent' in section 'Timer'

Nach einiger Recherche habe ich gefunden, dass der Parameter 'Persistent' wohl erst ab systemd 220 unterstützt wird. Das macht mich doch ein wenig ratlos
gerade, weil ich davon ausgehe, dass 'Persistent' sicherstellt, dass ein verpasster und jetzt überfälliger Dienst nachgeholt wird.
Tut mir leid, dass ich nicht wirklich helfen konnte und mehr Fragen entstanden sind.

 

[josef-wien]

Tut mir leid, dass ich nicht wirklich helfen konnte

Deine sehr lobenswerten Forschungen zeigen, daß die Eingangsfrage

Kann ich den auch irgendwie für opensuse 13.1 installieren?

mit "nein" zu beantworten ist (außer man will sich sein eigenes systemd zurechtbasteln).

Nach einiger Recherche habe ich gefunden, dass der Parameter 'Persistent' wohl erst ab systemd 220 unterstützt wird.

Es funktioniert ab 212: https://github.com/systemd-cron/systemd-cron

 

[Boreas]

@josef-wien
danke für den Hinweis. Ist doch aber seltsam, warum ist fstrim.timer so konfiguriert in 13.2, dass ein Fehler auftritt - scheint als habe man das nicht getestet :???:

 

[josef-wien]

scheint als habe man das nicht getestet

Damit dürftest Du richtig liegen.