LaufwerksTRIM bei SSDs in Mint20

[csx111]

Über die Datei fstrim.timer in /lib/systemd/system

[Unit]
Description=Discard unused blocks once a day
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

wird festgelegt, dass TRIM täglich beim erstmaligen Start erfolgen soll (Standard ist weekly).

Die Datei fstrim.service im selben Verzeichnis bestimmt, dass alle über fstab eingebundenen Laufwerke davon erfasst werden sollen.

[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/fstrim --fstab --verbose --quiet
ProtectSystem=strict
ProtectHome=no
PrivateDevices=no
PrivateNetwork=yes
PrivateUsers=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
SystemCallFilter=@default @file-system @Basic-io @sYsTeM-service

Bei mir sind das von 3 Laufwerken (Partitionen), sda1, sda2 und sda3, die beiden letzten (ext4-Laufwerke), eingehängt durch die entsprechenden UUID-Einträge in fstab.

Gleichwohl, der Aufruf von „journalctl | grep fstrim" im Terminal zeigt, dass nach der täglichen automatisierten TRIM-Ausführung immer nur ein Laufwerk, sda2 (das mit dem Betriebssystem Linux Mint), getrimmt wurde, sda3 dagegen wird nicht erwähnt

Erfolgt ein manuelles Trimmen durch den Aufruf desselben Befehls"sudo fstrim --fstab --verbose" im Terminal, werden dagegen, wie vorgesehen, die beiden über fstab eingebundenen Laufwerke sda2 und sda3 getrimmt, und entsprechend bestätigt.

Weiß jemand Rat, warum dies über den automatisierten Aufruf (mit demselben Befehl) nicht auch so funktioniert?

 

[Iapetos]

Könntest du bitte deine fstab und evtl. crypttab hier posten?

 

[csx111]

In fstab gibt es, außer den Kommentarzeilen dazu nur die beiden Einträge

UUID=fa65100... / ext4 noatime,errors=remount-ro 0 1
UUID=e1a142c... /media/DATEN ext4 noatime,nosuid,nodev,nofail 0 0

Die genannten (in fstab natürlich vollständigen) UUIDs stimmen mit den Werten nach Aufruf von blkid überein. Beide Laufwerke werden nach dem Start auch als eingehängt gemeldet ("mounted").

Eine Datei names crypttab habe ich nicht (auch kein verschlüsseltes Laufwerk), nur eine crypttab.5.gz in /usr/share/man/man5

 

[Iapetos]

Der fstrim.service scheint einen Fehler zu enthalten: --quiet wird von fstrim nicht unterstützt, die Option heißt richtig --quiet-unsupported (kann aber auch daran, liegen, dass Mint eine alte Version verwendet, das wäre aber ungewöhnlich und zudem sehr wahrscheinlich dokumentiert); siehe fstrim. Ansonsten fische ich hier auch im Trüben.

Hier meine fstrim.service (aus Fedora 33):

[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)
ConditionVirtualization=!container
 
[Service]
Type=oneshot
ExecStart=/usr/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
PrivateDevices=no
PrivateNetwork=yes
PrivateUsers=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
SystemCallFilter=@default @file-system @basic-io @system-service

PS: Wenn du deine Code-Blöcke in Code-Blöcke setzt, pingst du nicht unfreiwllig Nutzer an. 😉

 

[csx111]

PS: Wenn du deine Code-Blöcke in Code-Blöcke setzt, pingst du nicht unfreiwllig Nutzer an. 😉

Das will ich gerne künftig tun (kannte die Funktion noch gar nicht ), sieht auch viel besser aus. Danke für den Hinweis. Doch was bedeutet "pingst Du nicht unfreiwillig Nutzer an?

Wenn ich in Mint im Terminal

fstrim -- help

aufrufe, erscheint bei den Optionen u. a.

    --quiet         suppress error messages

also ohne den Zusatz unsupported. Das dürfte demnach okay sein. Doch ob mit oder ohne quiet ist das unbefriedigende Ergebnis leider dasselbe.

 

[Iapetos]

Wenn du dir deinen Eingangspost anschaust, siehst du, dass du die Nutzer @Basic und @sYsTeM angepingt hast. Ist aber auch nicht schlimm.

Spannend. Mein fstrim wirft eine andere Hilfestellung aus.

Aus der btrfs-Manpage:

If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period of low system activity will prevent latent interference with the performance of other operations. Also, a device may ignore the TRIM command if the range is too small, so running a batch discard has a greater probability of actually discarding the blocks.

Könnte sein, dass in deiner zweiten Partition einfach nichts passiert, was getrimmt werden müsste. Das könnte z. B. dann der Fall sein, wenn dort keine oder nur zusammenhängende Schreiboperationen stattfinden. Das Gerät meldet dann (stumm, weil --quiet), dass dort nichts zu tun ist.

 

[csx111]

... Könnte sein, dass in deiner zweiten Partition einfach nichts passiert, was getrimmt werden müsste. ...

Durchaus, ist aber nicht so. Führe ich manuell

fstrim --all --verbose --quiet

aus, wird TRIM richtigerweise für beide Partitionen ausgeführt, und die Ergebnisse entsprechend angezeigt.

/media/DATEN: 300,5 GiB (322655297536 bytes) trimmed on /dev/sda3
/: 1,5 GiB (1597313024 bytes) trimmed on /dev/sda2

 

[Iapetos]

Ich wühle mich mal durch die Changelogs von util-linux. Es könnte ein bereits gefixter Bug sein, der aufgrund der zähen Update-Strategie von Ubuntu/Mint noch in der aktuellen Distribution vorhanden ist. Könntest du bitte deine Version von util-linux verraten?

Könnte dieser Bug zu deinem Problem passen? Falls ja, kommentiere im fstrim.service die Zeile ProtectSystem=strict aus.

Hier noch ein ähnlicher Bug. Alles in allem liegt es wohl an dem Service-File bzw. dessen Interpretation von fstrim.

 

[csx111]

Meine Version von util-linux ist 2.34-0.1ubuntu9.1. Ich hab' auch schon versucht, die neuere Version 2.36... drüberzubügeln, doch die wird vom System nicht zur Installation akzeptiert.

Ich erinnere mich, dass das TRIM auf beiden Partitionen tatsächlich auch einmal geklappt hat, und auch so geloggt wurde. Aber nur einmal, und ich kann mich nicht erinnern, was inzwischen geschah. Da ich an meinem System nichts geändert habe, bis auf die normalen Mint-Updates, habe ich große Sympathie für den Ansatz, dass eines davon die Ursache gewesen sein kann/ muss.

Die Zeile ProtectSystem=strict hatte ich bereits vor einigen Tagen mal versuchsweise auskommentiert, brachte aber nichts. Aktuell habe ich in fstrim.service alle Zeilen mit "Protect..." und "Private..." auskommentiert (sind beim manuellen Trimmen ja auch nicht nötig), und werde das Ergebnis dann morgen früh sehen können.

Danke übrigens für Deine freundliche Mühe und Unterstützung.

 

[csx111]

Die vorstehend genannte Auskommentierung aller Zeilen mit "Protect..." und "Private..." in der Datei fstrim.service hat auch nichts gebracht. Wieder wurde nur sda2 getrimmt

Jan 13 05:13:04 ... fstrim[568]: /: 5,5 GiB (5875314688 bytes) trimmed on /dev/sda2
Jan 13 05:13:04 ... systemd[1]: fstrim.service: Succeeded.

Ein direkt anschließendes manuelles TRIM, s. o., ergab dagegen

/media/DATEN: 300,5 GiB (322690781184 bytes) trimmed on /dev/sda3
/: 241,6 MiB (253292544 bytes) trimmed on /dev/sda2

Das heißt, dass beim automatisierten Trim tatsächlich nur sda2 getrimmt wurde, und nicht etwa nur ein Log-Fehler vorliegt.

Jetzt werde ich die beiden letzten Zeilen in der fstrim.service auch noch auskommentieren.

 

[csx111]

Auch mit dieser fstrim.service

[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/fstrim --fstab --verbose
# ProtectSystem=strict
# ProtectHome=no
# PrivateDevices=no
# PrivateNetwork=yes
# PrivateUsers=no
# ProtectKernelTunables=yes
# ProtectKernelModules=yes
# ProtectControlGroups=yes
# MemoryDenyWriteExecute=yes
# SystemCallFilter=@default @file-system @basic-io @system-service

mit zahlreichen Auskommentierungen ergibt sich keine Lösung des Problems. Nur ein eingehängtes fstab-Laufwerk wird getrimmt, das zweite immer noch nicht. Das TRIM-Ergebnis ist wie vorstehend in #10 (nur die angezeigten Bytes sind geringfügig unterschiedlich).

 

[Iapetos]

Besteht die Möglichkeit, dass du eine andere Distribution (also nicht Ubuntu) ausprobierst?

 

[csx111]

Grundsätzlich schon; die müsste ich dann aber auf eine SSD installieren, und da hab' ich gerade keine frei. Da auch ein manuelles gelegentliches TRIM ausreicht, ist es gewiss weniger mühevoll, auf eine Fehlerkorrektur bei Mint zu warten, als mein System mit einem anderen Linux komplett neu aufzusetzen.