TRIM unter Linux deaktivieren wegen SATA-Adapter

[Basic.Master]

Hallo zusammen,

vor ein paar Jahren hatte ich mein X41 mit einer SSD aufgerüstet, dank Forum bzw. Wiki. Die Problematik mit TRIM betrifft auch Linux, weil die Kombi Adapter/SSD angibt, TRIM zu können, es dann aber doch nicht kann. Mit Ubuntu 12.04 (oder 10.04?) war das noch kein Problem, weil TRIM dort standardmäßig ausgeschaltet ist.

Aber z.B. 18.04 schaltet TRIM standardmäßig ein, wenn die SSD angibt, es zu können (sie kann es ja, aber der Adapter IDE/SATA wohl die Befehle nicht weitergeben). Es gibt keine Kerneloption, um TRIM generell auszuschalten, nur eine hartcodierte Blacklist für bestimmte Geräte, die hier leider nichts bringt. Entsprechend hängt der Bootvorgang dann wiederholt für mehrere Sekunden und auf der Konsole tauchen ATA-Fehlermeldungen auf.

Allerdings kann man TRIM pro Gerät ausschalten, automatisch beim Bootvorgang via udev. Dazu mit Root-Rechten eine Datei /etc/udev/rules.d/10-disable-trim.rules anlegen, mit folgendem Inhalt:

KERNEL=="sda", ATTR{queue/discard_max_bytes}="0"

"sda" steht für die erste Platte, daher ggf. den Befehl wiederholen und anpassen bzw. den Wert "sda" verallgemeinern, um auch andere Geräte abzudecken.

Zu diesem speziellen Problem habe ich hier bisher nichts gefunden (nur jemanden bei Reddit, der dasselbe Problem hatte, aber nicht weiterkam). Vielleicht sind andere hier ja auch davon betroffen...

 

[linrunner]

Da 18.04 kein Online Discard aktiviert, genügt es eigentlich den Cron-Job für Batched Discard /etc/cron.weekly/fstrim zu deaktivieren, z.B., durch umbenennen in fstrim~.

https://wiki.ubuntuusers.de/SSD/TRIM/#Automatisches-TRIM-ab-Ubuntu-14-10

 

[Basic.Master]

Mit 18.04 läuft das (zumindest bei Ubuntu MATE) nicht mehr mit Cron, sondern via systemd, zeigt sich gerade. Der Job scheint interessanterweise aber tatsächlich die Ursache zu sein, denn wenn ich die udev-Regel wieder rausnehme und testweise /sbin/fstrim umbenenne (wollte jetzt nicht suchen, wie ich den Job in systemd deaktivieren kann), bootet das ThinkPad bei Neustart weiterhin ohne die Fehlermeldungen. Und auch wenn ich danach die Umbenennung wieder rückgängig mache, scheint der erfolgreiche Durchlauf (ohne, dass fstrim gefunden wurde) gereicht zu haben. Halt bis das nächste Mal der wöchentliche Job ausgeführt werden würde. Daher bleibe ich mal sicherheitshalber bei der udev-Regel; so kann da auf keinen Fall irgendwas reinfunken, egal woher...

 

[cuco]

sudo systemctl disable fstrim.timer

Das müsste den SystemD-Dienst deaktivieren.

 

[Basic.Master]

OK, habe den Dienst damit deaktivieren können, danke.

Das Setzen von "discard_max_bytes" auf 0 hat nicht (komplett) geholfen. Wenn beim Formatieren getrimmt wird bzw. man testweise von Hand fstrim aufruft, wird trotzdem der ioctl-Call BLKDISCARD ausgelöst, der aktuelle Zugriff friert ein und man bekommt Timeouts im Syslog. Musste daher beim Installieren die Partitionen vorher manuell formatieren mit "mkfs.ext4 -E nodiscard" bzw. "mkfs.btrfs -K". Ich kann im Kernel-Quellcode auch nicht wirklich erkennen, wieso discard_max_bytes von 0 den Call zum Abbruch zwingen sollte....auch wenn die Doku /Documentation/block/queue-sysfs.txt dieser Variable diese Funktion zuschreibt...

Gibt es mittlerweile vielleicht Adapter von IDE auf mSATA, die TRIM durchlassen? Das wäre auf Dauer wohl einfacher.

 

[Pferdle]

Gibt es mittlerweile vielleicht Adapter von IDE auf mSATA, die TRIM durchlassen? Das wäre auf Dauer wohl einfacher.

Wird es nicht geben und wäre auch sinnlos.
IDE kann grundsätzlich kein TRIM. Der Chipsatz unterstützt es schlichtweg nicht. Wurde erst mit SATA erfunden. Egal was und wie auch immer am IDE dran hängt, der Befehl kommt da nicht an. Die komplette Kette Betriebssystem - Chipsatz - Kabel - SSD müssen TRIM-fähig sein, sonst wird das nix.

 

[Basic.Master]

Irgendwo hatte ich was von "passthrough" gelesen, daher dachte ich, der Befehl könnte da irgendwie durchgereicht werden, ohne dass er IDE bekannt ist.

Habe mir jetzt nochmal das andere Attribut "provisioning_mode" angesehen, das im weiteren Verlauf der oben verlinkten Diskussion auf der Kernel-Mailingliste als "Fallback" erwähnt wurde (wobei mir nicht klar ist, warum der Kernel dort 2016 zu alt war, denn auch in der aktuellen v4.19 sehe ich keine Änderung im Verhalten, jedenfalls im Quellcode). Demnach wird "discard" (wie TRIM auch genannt wird) deaktiviert, wenn unter bestimmten Umständen bei der Ausführung eines Befehls vom Gerät ein Fehler zurückkommt (in meinem Fall kommt ja leider kein Fehler, sondern "nur" ein Timeout). Entsprechend wird dieser Mode dann auf "disabled" gesetzt und man kann auch im Kernel-Quellcode nachvollziehen, dass dann das zuständige Bit QUEUE_FLAG_DISCARD zurückgesetzt wird.

Wenn man also manuell bzw. via udev das Attribut "provisioning_mode" auf "disabled" setzt, wird TRIM tatsächlich deaktiviert. Ein "strace fstrim -a" zeigt, dass der entsprechende ioctl jetzt mit "-EOPNOTSUPP (Operation not supported)" abbricht - Ziel erreicht!

Das habe ich jetzt in folgende udev-Regel gegossen:

KERNEL=="sda", ATTR{device/scsi_disk/0:0:0:0/provisioning_mode}="disabled"

Anscheinend kann man das auch irgendwie elegant direkt auf das scsi(_disk)-Subsystem mappen lassen, anstatt den langen, verschachtelten Attributpfad zu benutzen, aber ich habe es nicht hinbekommen. Aber so funzt es ja auch.

Ergo: Bei der Installation den Wert manuell via Konsole setzen, und, bevor man den Neustart-Prompt bestätigt, die udev-Regel unter /target/etc/udev/rules.d einspielen.