mdadm raid, LUKS und fehlendes TRIM führen zu read-only mount auf SSDs

[SFFox]

Vorwort:
Hier geht es um Aufmerksam bzgl. eines potentiellen Fehlers oder einer bedingten Verhaltensweise von LUKS in Verbindung mit SSDs und fehlendem TRIM. Es ist keine Anleitung und kein Tutorial, sondern nur meine begrenzte Diagnose und ein "Workaround", der bei mir funktioniert hat. Wer seine Daten nicht richtig gesichert hat, sollte das hier nicht unbedingt nachahmen.

---

TLDR:
In meinem mdadm Raid0 LuksEncrypted SSD Mount musste "discard" allowed werden, damit sie TRIM ausführen können. Ohne TRIM verstand das System nicht, welche Blöcke wirklich belegt sind und welche nicht, weil Luks sie weiterhin claimed, obwohl das Dateisystem noch freien Speicher anzeigt. Das führt dann trotz vermeintlich freiem Speicherplatz bei Schreibvorgängen zu einem Dateisystem-Fehler (bei mir EXT4) und dem error 5 im Log, weil die SSD den Write verweigert.

TRIM kann z.B. beim LuksOpen mit "--allow-discards" oder auch in der "/etc/crypttab" enabled werden. Recherchiert was zu euren Einbindungen am besten passt. Checkt zusätzlich ob fstrim as wiederkehrender Systemprozess automatisch regelmäßig durch läuft.

Auf einer 64GB SSD im selben System, die ich 50% 50% in zwei Partitionen geteilt, in Raid0 und Luks gepackt habe, ist es nicht zu reproduzieren (es ist eine andere SSD an einen anderen Controller... vielleicht ist es eine Inkompatibilität). Vielleicht hat es beim Raid0 damit zu tun, dass die Dateien 50:50 geschrieben werden auf verschiedene Laufwerke, was Datenblock Zuordnung schwierig macht? Vllt. ist der SSD Controller buggy und auf TRIM infos angewiesen? Ggf. stimmt das Zusammenspiel Hardware/Software hier nicht? Who knows.

Ich untersuche weiter.

TURNS OUT:
Es sind 2x Sandisk Ultra 3D mit 4TB. Wenn TRIM bei denen nicht sauber läuft durch die ganzen Abstraktionsschichten kommt man um einen Daten-Refresh nicht herum. Ich habe also alles geplättet, das mdadm neu angelegt, Luks neu angelegt, "allow discards" direkt als Flag in den Header gesetzt und die Daten vom Backup Raid1 wieder neu aufgespielt. Anschließend habe ich noch mal ein fstrim durch laufen lassen (die SSDs sind beim TRIM auch noch mal gut warm geworden, ist schnell und erfolgreich durch gelaufen) und ich habe bisher meine konstanten 1GB (also 2x SATA SSD Bandbreite) an konstanter Lese-/Schreibgeschwindigkeit zurück (wenn es jetzt nicht ein Haufen kleinst-Dateien sind). 👍

Der Langzeitgebrauch wird zeigen, ob das in eine halben oder ganzen Jahr noch mal nötig ist, oder ob die Controller-Firmware jetzt selbst regeln kann das Performance-Level zu halten.

---

Hey zusammen.

Ich betreibe schon super lange in meinem HomeNAS/Server hardware-unabhängige Raids auf mdadm Basis.
Die Grundlage dafür gab es schon seit meinem AM1 AMD Athlon 5350, ging über einen i3-4130T, einen Ryzen 3700X und ist jetzt bei einem Ryzen 5950X mit B550 Board angekommen. Ich teile euch mal meine heutige Erkenntnis mit, auf die man sicher auch selbst kommen kann, aber über die ich naiv nie nachgedacht habe.

Der aktuelle Stand ist:

• eine primäre NVMe SSD mit 240GB fürs OS
• 2x 4TB SATA SSD mdadm RAID0 (LuksEncrypted)
  • mein "produktives" Samba-Drive, wo alle im Haushalt ihre Daten drauf lagern
• 3x 8TB HDD RAID1 (LuksEncrypted)
  • das Backup für das Produktiv-Drive
  • eine Platte war spare, ich synce sie aber jetzt doch direkt mit, damit das nicht erst im kritischen Moment passiert, wenn eine bereits ausgefallen ist
  • eine offsite 8TB liegt verschlüsselt in der Büro-Schublade (3-2-1 yeah)
• 2x 1TB HDD RAID0 (LuksEncrypted)
  • Laufwerk für temporäre Daten, oft sequential "raw" Video, ist nur ein Raid0 um die 2.5Gbit im Netzwerk besser auszureizen
• 1x 3TB HDD (LuksEncrypted)
  • Speicherort für Boot-Drive-Images aller Rechner im Haushalt

Ich binde nach einem reboot meine Mounts über ein shell-script ein, das einmal das Passwort abfragt, mit dem es alle LuksCrypts öffnen kann.

Shit Happens
Jetzt ist mir bei einem Füllstand von ~5TB folgendes mit meinem produktiven Samba-Drive passiert:
Beim Kopieren des letzten rendered Videos kam es immer wieder zu Fehlern und Hängern im Dateisystem. Die SSDs waren in IO zu 100% ausgelastet während nur kbyte-weise Schreibprozesse in Monitor-Anwendungen zu sehen waren. Nachdem file transfers über das Netzwerk irgendwann abgebrochen sind wurde der LuksDrive Mountpoint in den "emergency_ro" (Emergency Read Only) Modus gesetzt, also Schreibschutz.

Die beiden SSDs haben ~180 Betriebsstunden und sind bzgl. SMART unauffällig (saubere Werte, quick und long Test problemlos bestanden).

Nachdem ich dann mit fsck (-y) das EXT4 Dateisystem checken und im zweiten Durchlauf reparieren konnte, war es nach Neueinhängung wieder beschreibbar gemounted. Nach dem ersten großen Schreibvorgang ist es allerdings direkt wieder im Read Only Modus gelandet.

[86597.650812] EXT4-fs (dm-3): Delayed block allocation failed for inode 52887565 at logical offset 55296 with max blocks 1024 with error 5
[86597.650820] EXT4-fs (dm-3): This should not happen!! Data will be lost
[86732.597087] EXT4-fs (dm-3): failed to convert unwritten extents to written extents -- potential data loss!  (inode 142802951, error -5)

Turns out
LuksEncrypted SSDs müssen "discard" allowen, damit sie TRIM ausführen können. Ohne TRIM versteht das System nicht, welche Blöcke wirklich belegt sind und welche nicht, weil Luks sie weiterhin claimed, während das Dateisystem aber den logischen freien Speicher anzeigt. Bei einem Schreibvorgang auf einem "vollen ungetrimmten" Laufwerk kommt es dann zu Fehlern. Bei HDDs (extra noch mal stupide getestet mit dem 2x 1TB Raid0) ist das irrelevant.

Was haben wir gelernt?
TRIM ist wichtig bei LuksEncrypted SSDs. Die Default-Konfiguration aller beteiligten Pakete unter Ubuntu Server sorgt dafür, dass TRIM nicht automatisch funktioniert. Da muss man sich schon selbst drum kümmern. Checkt zusätzlich ob fstrim as wiederkehrender Systemprozess automatisch regelmäßig durch läuft.
Vielleicht hilft es ein paar googlenden Leuten der Beitrag ist 8 Minuten später schon im Google Suchindex gelandet, die sind echt flott.

 

[KillerCow]

Was genau ist dafür die Ursache? Ohne discard zu arbeiten bedeutet ja erstmal nur, dass die SSD keine ungenutzten Blöcke vorsorglich freiräumen kann. Das kostet irgendwann Performance (wegen "erase-before-write"), aber Datenverlust darf dabei doch nicht auftreten!?

Bei LUKS wird absichtlich auf discard verzichtet, damit man schlechter erkennen kann, welche Blöcke Nutzdaten enthalten und welche nicht. So habe ich das zumindest verstanden.

 

[SFFox]

Was genau ist dafür die Ursache?

Ich bin nicht tief genug unterwegs auf Systemebene, um dir ein "warum ist das so?" zu beantworten. Ich konnte das jetzt nur durch Testing eingrenzen (100% reproduzierbar) und habe im Nachhinein einen ähnlichen Leidensgenossen gefunden:
https://bbs.archlinux.org/viewtopic.php?id=296196

Ohne discard zu arbeiten bedeutet ja erstmal nur, dass die SSD keine ungenutzten Blöcke vorsorglich freiräumen kann. Das kostet irgendwann Performance (wegen "erase-before-write"), aber Datenverlust darf dabei doch nicht auftreten!?

Genau das habe ich auch gedacht. "Datenverlust" trifft immerhin keine Bestandsdaten, sondern nur die neuen.
Schön ist das trotzdem nicht. Auch von der Usability bedeutet das ja, dass der wöchentliche TRIM check einfach nicht ausreicht, wenn man nahe an der Füllkapazität ist mit seinem Datenbestand und mehrere große Dateien kopiert/löscht.

Bei LUKS wird absichtlich auf discard verzichtet, damit man schlechter erkennen kann, welche Blöcke Nutzdaten enthalten und welche nicht. So habe ich das zumindest verstanden.

Das hab ich auch gelesen und das ist ja auch total sinnvoll so im Rahmen der maximal möglichen Datensicherheit. Aber scheinbar funzt das nicht zu 100% zuverlässig.

 

[Donnerkind]

Vielleicht hat das bedarfsgesteuerte Trimmen vor dem Schreiben so lange gedauert, dass das Raid an einen Hardware-Defekt dachte?

 

[SFFox]

@Donnerkind Puh... das Raid lag eine Woche im idle bevor jetzt am Wochenende eine 800MB große Video-Datei geschrieben wurde und hatte 2.7TB freien Speicher als der Fehler zum ersten mal aufgetreten ist. Das hätte ja wohl zum Hardware-Trimmen sowas von gereicht.

Nach fsck Reparatur, remount, Löschung der Datei und neuem Versuch kam es zum selben Ergebnis. Den Spaß habe ich zwei oder drei mal Wiederholt.

Nachdem ich das Laufwerk mit "--allow-discards" eingebunden habe und erfolgreich fstrim -v ausführen konnte war die Rückmeldung, dass 2.7TB mit TRIM freigegeben wurden. In Folge konnte ich die Datei und auch weitere 22GB Testdaten wieder problemlos schreiben.
Der Fehler hängt auch nicht mit SMB zusammen, sondern trat auch auf, wenn ich einen internen filetransfer versucht habe.

Es hat also zu 100% mit dem TRIM zu tun. Vielleicht gibt es hier ja jemand kundigen, der uns erleuchten kann warum. Wie gesagt, intuitiv und verlässlich finde ich das überhaupt nicht.

 

[KillerCow]

dass das Raid an einen Hardware-Defekt dachte

Interessante Idee. Wäre spannend, welche Timeouts ext4 und mdadm dafür ansetzen.

Im journal gibt es keine weiteren Logeinträge, die irgendwie dazu passen? SMART-Daten der SSD?

 

[SFFox]

@KillerCow
Absolut nicht leider. Ich habe einen short und long Smart Test laufen lassen auf beiden SSDs ohne negatives Ergebnis (beide ~170 Betriebsstunden, die hängen halt viel im Leerlauf, das zählt er also auch gar nicht als Betriebsstunden), keinerlei Errors o.ä. und auch keine Input/Output Fehler (die kenne ich von defekten Controllern / SATA Laufwerken auch schon von früher und werden ja teilweise auch in SMART hochgezählt).
Die volle Leistung war auch nach dem TRIM instant wieder da.

 

[KillerCow]

wenn man nahe an der Füllkapazität ist mit seinem Datenbestand und mehrere große Dateien kopiert/löscht.

Die SSD wird dann halt schnarch langsam, weil sie Blöcke erst löschen muss, um die neuen Daten zu schreiben, wofür sie mit discard immer welche in der Hinterhand hat.
Darum "soll" man SSDs ja auch nicht komplett vollschreiben. Ohne discard gibt es irgendwann keine leeren Blöcke mehr (wenn viel geschrieben und gelöscht wird) und dann große Dateien schreiben... Ich bin da auch eher auf der Seite von @Donnerkind oder es ist ein Bug. Aber definitiv ist das kein "normales" Verhalten.

Bekommt man denn irgendwie heraus, wieviele leere Blöcke eine SSD noch zur Verfügung hat? Bei Consumerplatten vermutlich eher nicht, aber ich muss direkt mal im Büro bei unseren NVMEs schauen ^^

Insgesamt aber ein gute Hinweis mit LUKS und discard!

 

[SFFox]

Ich vermute ohne discard kann auch die Hardware der SSD nicht sagen, ob Blöcke frei gegeben werden können, oder nicht. Wenn man sich den Datenbestand als große Zip Datei vorstellt, die ihre Größe nicht reduziert bei Dateilöschung (kennt man z.B. ja auch von growing virtual disk images in VMs), dann ist das auch irgendwie anschaulich. Wobei das wiederum nicht erklärt, warum es bei HDDs egal wäre.

Der Write Speed einer nahezu vollen SSD ist natürlich langsamer, wenn keine freien Blöcke zur Verfügung stehen, aber kilobyte-Speed ist selbst da schon zu wenig. Ich vermute aber auch, dass da unter der Haube irgendwas nicht wie beabsichtigt läuft.

 

[kieleich]

LuksEncrypted SSDs müssen "discard" allowen, damit sie TRIM ausführen können.

Hat mit der SSD nichts zu tun.

Bei Verschlüsselung gibt es die Vorstellung das man freien Speicher, auch mit Zufall Daten, gefüllt halten müsse damit, ein Angreifer nicht sehen könne, WIEVIEL Daten existieren und WO diese liegen. Da sich daraus Rückschlüsse aus den Daten ziehen lassen zB manche Dateisysteme haben ein "Fingerabdruck" (je nachdem wo die Metadaten, Backup Superblöcke liegen) da könne man wissen welches Dateisystem man verwende u.s.w

Ein Haufen Quark jedenfalls. Die Daten sind verschlüsselt. Der Rest wird in der Praxis eher keine Rolle spielen

Aber desdewegen jedenfalls verhindert LUKS standardmässig den TRIM. Bei LUKS 2 ist es aber inzwischen möglich dies dauerhaft zu erlauben (persistent im Header gespeichert). Die allow-discard Optionen oder crypttab oder Kernelparameter Flags entfallen.

Ohne TRIM versteht das System nicht, welche Blöcke wirklich belegt sind und welche nicht, weil Luks sie weiterhin claimed.

Das passiert mit unverschlüsselten Daten genau so wenn nicht getrimmt wird.

[86597.650812] EXT4-fs (dm-3): Delayed block allocation failed for inode 52887565 at logical offset 55296 with max blocks 1024 with error 5
[86597.650820] EXT4-fs (dm-3): This should not happen!! Data will be lost
[86732.597087] EXT4-fs (dm-3): failed to convert unwritten extents to written extents -- potential data loss!  (inode 142802951, error -5)

Das hier ist ein ganz anderes Problem da hat sich das Dateisystem selber verschlückt! Kann natürlich trotzdem ein Problem der SSD sein.

Aber SSD ohne TRIM dürfen, wenn überhaupt dann vielleicht nur etwas langsamer werden aber Schreibzugriffe ablehnen darf sie nicht sonst ist die SSD selbst, nicht korrekt in ihrer funktion!

TRIM ist optional und kann helfen bei der performanz aber fehler dürfen daraus keine entstehen es macht ja auch kein Sinn. Der trim kommt auf den meisten system wöchentlich aber du könntest ja eine Woche lang 24/7 nonstop ne mega kopieraktion machen und das muss dann auch funktionieren!

du hast mit trim vll ein symptom umschifft aber da ist irgendwo ein faules Ei im system dann

 

[Donnerkind]

@Donnerkind Puh... das Raid lag eine Woche im idle bevor jetzt am Wochenende eine 800MB große Video-Datei geschrieben wurde und hatte 2.7TB freien Speicher als der Fehler zum ersten mal aufgetreten ist. Das hätte ja wohl zum Hardware-Trimmen sowas von gereicht.

Das schöne Idle nützte dir halt nichts, weil ja eben kein Background-Trim ausgeführt wurde.

Aber desdewegen jedenfalls verhindert LUKS standardmässig den TRIM. Bei LUKS 2 ist es aber inzwischen möglich dies dauerhaft zu erlauben (persistent im Header gespeichert). Die allow-discard Optionen oder crypttab oder Kernelparameter Flags entfallen.

Richtig. Es genügt, das Luks-Volume einmal händisch mit allow-discards zu mounten. Damit wird die Option in den Header geschrieben.

 

[kieleich]

Man muss es setzen mit ""cryptsetup refresh <gewünschte optionen siehe man page> --persistent""


Schreiben muss trotzdem immer funktionieren. Dafür hat die SSD, ihre internen Reserven und Wearlevel Mechanismen. Auch wenn die dann ein wenig Jenga spielen muss mit ihren freien Blöcken Und auf die Performanz geht

Apropos Performanz, hier kann TRIM durch aus auch mal das Problem sein denn, Dateisysteme brauchen lange um jedes Quentchen freien Platz zu lokalisieren, und das resultiert dann in viel Klein-Klein Hickhack TRIM Befehle.

Dafür hat fstrim die --minimum Funktion das Speicherbereiche die kleiner als dieses Minimum sind, ignoriert werden. Dann wird der Dreck unterm Teppich nicht mit getrimmt aber im großen ganzen schon, das Dateisystem ist schneller fertig, die SSD hat weniger TRIM Befehle für größere Bereiche wo es sich lohnt und insgesamt dann doch genug freie Blöcke, vorausgesetzt das Dateisystem war nicht eh schon praktisch voll.

Bei vollem Dateisystem auch normal das nicht getrimmt wird! fstrim findet da ja nichts, und trotzdem muss das Dateisystem noch funktionieren. Da darf eine SSD keine Fehler produzieren ganz einfach.

 

[SFFox]

Hat mit der SSD nichts zu tun.

Ja stimmt, im Textverlauf sollte klar sein, dass es um die Mounts geht. Hab den Satz angepasst.

Ein Haufen Quark jedenfalls. Die Daten sind verschlüsselt. Der Rest wird in der Praxis eher keine Rolle spielen

Ja das denk ich mir auch, Sicherheitsbedenken habe ich mit "discard" keineswegs.

Aber desdewegen jedenfalls verhindert LUKS standardmässig den TRIM. Bei LUKS 2 ist es aber inzwischen möglich dies dauerhaft zu erlauben (persistent im Header gespeichert). Die allow-discard Optionen oder crypttab oder Kernelparameter Flags entfallen.

Schön, dass sie das mit LUKS2 verbessert haben 👍

Das passiert mit unverschlüsselten Daten genau so wenn nicht getrimmt wird.

Hier würde ich sagen "kommt drauf an". Irgendwas läuft hier schief und macht eben einen Unterschied zwischen verschlüsselt und unverschlüsselt. Prinzipiell hast du aber Recht, so sollte es sein.

Das hier ist ein ganz anderes Problem da hat sich das Dateisystem selber verschlückt! Kann natürlich trotzdem ein Problem der SSD sein.

Ich halte es für ein Software Problem.

Aber SSD ohne TRIM dürfen, wenn überhaupt dann vielleicht nur etwas langsamer werden aber Schreibzugriffe ablehnen darf sie nicht sonst ist die SSD selbst, nicht korrekt in ihrer funktion!

Noch mal sorry an der Stelle, es ging um die Mounts. Aber ja, es gibt auch alte SSDs ohne TRIM und die bedeuten ja auch nicht einfach Datenverlust.

TRIM ist optional und kann helfen bei der performanz aber fehler dürfen daraus keine entstehen es macht ja auch kein Sinn. Der trim kommt auf den meisten system wöchentlich aber du könntest ja eine Woche lang 24/7 nonstop ne mega kopieraktion machen und das muss dann auch funktionieren!

Genau!

du hast mit trim vll ein symptom umschifft aber da ist irgendwo ein faules Ei im system dann

Und jetzt die 1000€ Frage, was kann es sein? Interne und externe Kopieraktionen crashen ohne TRIM.
Ich habe da nix groß kompliziertes am Laufen. Das ist ein Stock Ubuntu Server mit classic mdadam, luks und modernem 6.17er Kernel. Es gibt noch n bisschen extra Software Dienste, aber die haben jeweils keine echten Berührungspunkte mit Dateisystem- oder Hardware-Handling.

Vom RAID an sich ist es nicht abhängig. Der Leidensgenosse, den ich weiter oben verlinkt habe aus dem Arch Forum hat das gleiche Spiel mit seiner LUKS Boot-SSD. 🤷‍♂️

Da darf eine SSD keine Fehler produzieren ganz einfach.

Es sind auch keine SSD-"Fehler" (also bzgl. Hardware-Defekt), es sind Dateisystem-Fehler. Da ist allen bisherigen Tests nach die Software Schuld und nicht die Hardware. EXT4 sagt es sind 2.7TB frei, aber error 5 aus dem Log sagt die SSD gibt zurück "ich finde keine freien Bereiche zum Schreiben" und EXT4 sagt dann gibt's jetzt emergency read only remount.

 

[Donnerkind]

Apropos Performanz, hier kann TRIM durch aus auch mal das Problem sein denn, Dateisysteme brauchen lange um jedes Quentchen freien Platz zu lokalisieren, und das resultiert dann in viel Klein-Klein Hickhack TRIM Befehle.

Deswegen macht man das ja auch höchstens einmal die Woche. Auf einem Desktopsystem sollte das im Normalbetrieb jedenfalls ausreichend sein. Dann dauert ein kompletter Trim maximal 10 Sekunden.

Ich wollte es eben mal nachschlagen und habe mein Surface Go 3 angemacht. Da war fstrim tatsächlich noch deaktiviert -- es lief noch nie seit der Installation des Systems vor knapp zwei Monaten. 😱 Also mal ausgeführt und es dauerte knapp eine Minute auf der 256 GB großen /-Partition. Die SSDs in den Gos sind eher gemächliche Exemplare.

 

[SFFox]

Ich wollte es eben mal nachschlagen und habe mein Surface Go 3 angemacht. Da war fstrim tatsächlich noch deaktiviert -- es lief noch nie seit der Installation des Systems vor knapp zwei Monaten. 😱 Also mal ausgeführt und es dauerte knapp eine Minute auf der 256 GB großen /-Partition. Die SSDs in den Gos sind eher gemächliche Exemplare.

Bist du dort auch mit LUKS unterwegs? Schön jedenfalls, dass es dir aufgefallen ist, bevor es dir negativ aufgefallen ist. 👍

Ich habe mal die LLMs dazu befragt inkl. Log-Inhalt und muss sagen, dass die Antwort von Gemini 3 schon gar nicht so unwahrscheinlich scheint (mir ist bewusst, dass ich nicht die Fachkenntnis habe in Low Level Dateisystemen und es Halluzinationen sein können). Ich pack das mal als Spoiler in den Startbeitrag.

 

[Piktogramm]

Was mir an der Stelle fehlt, ist das systematische Vorgehen, von der niedrigsten Abstraktion zur je nächst höheren. Kein Check was SMART der Laufwerke sagt, keine check vom mdadm Array, stattdessen wilde Vermutung und Anpassung als Folge dessen. Das ist abenteuerlich!

Das Vorgehen normalerweise wäre so memtest, SMART, mdadm check, fscheck, bevor irgendwas auf das Volume geschrieben wird, geschweige denn an der Config geändert wird. Naja und Extrepunkte gibt es, wenn man sich Images der Laufwerke zieht.

die aktuelle Vermutung dazu ist, dass die SSD bei Einsatz von LUKS das bitrauschen nicht von echten Daten unterscheiden kann. Somit gehen irgendwann die leeren Blöcke aus und der im log auftretende "error 5" besagt, dass die SSD den Schreibvorgangs mangels freier Blöcke verwehrt.

Das ist gequirrlte ..
SSDs legen intern Verwaltungsdaten ab, wo welche logischen Adressen auf welche physischen Adressen gemappt gemappt sind und wie häufig der korrespondierende Ereaseblock bereits Schreib-/Löschzüglen hinter sich hat.

Beim Einrichten von dmcrypt sollte es eigentlich auch Standard sein, dass das gesamte Blockdevice einmal mit komplett mit zufälligem "Daten" gefüllt werden. Daher ist der Normalzustand eigentlich auch, dass jeder produktive Schreibvorgang für das Laufwerk ein Überschreiben bereits vorher belegter Blöcke ist. Wie voll das Dateisystem ist, welches auf dem via dmcrypt bereitgestelltem Blockdevice ist entsprechend egal, außer man hat discard (Trim) explizit aktiv.

Was bei SSDs vorkommen kann bei 100% Füllstand (also korrekt eingerichtetes cryptdevice, ohne discard), die Dinger in Probleme kommen beim Umsortieren von Sektoren auf andere, Ereaseblöcke. Das sollte aber im Logfile auftauschen, dass Laufwerk aus welchen Gründen in Timeouts gerannt ist. Wenn nicht ist es ein Bug vom Laufwerk und dann ist dem Laufwerk nicht zu trauen.

Naja oder es sind Defekte an Laufwerk/RAM, das mdadm write-hole, eine sich verrechnende CPU, seltene Softwarebugs, ....

 

[SFFox]

Was mir an der Stelle fehlt, ist das systematische Vorgehen, von der niedrigsten Abstraktion zur je nächst höheren. Kein Check was SMART der Laufwerke sagt, keine check vom mdadm Array, stattdessen wilde Vermutung und Anpassung als Folge dessen. Das ist abenteuerlich!

Da hast du aber nur das TLDR gelesen... Der error code im Log ist eindeutig: SSD verweigert den write. Ich hab jetzt 4 Tage lang analysiert und getestet. SmartCheck short/long war ebenfalls dabei und unauffällig (steht auch hier im Thread, hatte ich bereits vorher gemacht, hat jemand schon viel freundlicher nachgefragt).

Die einzigen Schreibvorgänge, die gemacht wurden waren fsck zum checken und danach um EXT4 zu reparieren und die eine Testdatei, um den Fehler zu reproduzieren.

Dabei (wie ebenfalls im Text zu lesen) habe ich meine Daten noch mal sicher auf einem HDD RAID1 und extern und somit überhaupt nix zu verlieren. Also ein ziemlich sicheres Abenteuer

Das Vorgehen normalerweise wäre so memtest, SMART, mdadm check, fscheck, bevor irgendwas auf das Volume geschrieben wird, geschweige denn an der Config geändert wird. Naja und Extrepunkte gibt es, wenn man sich Images der Laufwerke zieht.

Ja, memtest hab ich nicht extra gemacht, erwischt. Die Hardware is CurveOptimizer optimiert und mit dem RAM zusammen getestet worden. Jetzt bei dem zurückgehaltenen Schreibvorgang habe ich den RAM nicht neu getestet.
mdadm check kannst du bei Raid0 nicht nutzen, der hat ja gar keine Parität zum checken. Das brauchst du für Raid1, 5 o.ä.
Extrapunkte brauch ich nicht, alle Daten sind bereits sicher.

Beim Einrichten von dmcrypt sollte es eigentlich auch Standard sein, dass das gesamte Blockdevice einmal mit komplett mit zufälligem "Daten" gefüllt werden.

Das war weiter oben auch schon Thema. Das macht "man" zwar als Standard. Beim anlegen wusste ich aber, dass ich 5TB Füllstand haben werde, den ich von HDDs exportiere. Was drauf ist, ist verschlüsselt, das ist mir für ein bisschen Home-Data sicher genug und 8TB Abzug von der TBW einer SSD nicht wert.

Das ist gequirrlte ..

Ich war auch sehr lange bei einem "das kann doch nicht sein" bis es als einzige Erklärung konsistent übrig blieb + weitere betroffene im Netz. Ich lege meine Hand nicht für diese These ins Feuer, wenn du mir eine bessere Erklärung liefern kannst, dann her damit. Ich hoffe du hast Recht, denn das gefällt mir auch definitiv besser als "LUKS verweigert Schreibvorgänge ohne TRIM, wenn der Garbage voll ist". Ein bisschen weniger Judgement würde ich mir aber wünschen von jemandem, der nicht mal den kompletten Thread gelesen hat.

 

[Piktogramm]

@SFFox
Ich habe den Eingangspost gelesen, der benennt eine Lösung mit ungeordneten Theorien, was Ursache, Wirkung ist. Die "Lösung" die du bewirbst ist damit irgendwas zwischen, guter Tip (Discard bei dmcrypt aktivieren, wenn man das Risiko hinnehmen kann) bis gefährlich (jemand versucht sein kaputtes Array zu fixen).

Der error code im Log ist eindeutig: SSD verweigert den write.

Steht nicht im Logfile, da steht, dass EXT4 auf dem cryptdevice keinen Speicher allokieren kann. Da steht nichts von etwaigen (physischen) Laufwerken, noch dem mdadm Blockdevice. Wenn da wirklich keine weiteren Einträge sind, das dmcrypt, mdadm, ATA/AHCI/NCMe nicht schon vorher Fehler geworfen haben, dann ist das Ganze extrem merkwürdig.

Und CurveOptimizer.. Mein Desktop ist damit auch stabil, bis er es aller Tage nicht ist. Trotz memtest, furmark, ng-stress über Stunden.

 

[Donnerkind]

Bist du dort auch mit LUKS unterwegs? Schön jedenfalls, dass es dir aufgefallen ist, bevor es dir negativ aufgefallen ist. 👍

Nein, weil ich ohne angesteckte Tastatur booten können möchte. Das schließt ein, dass ich kein Passwort auf der TTY eingeben müssen möchte. Deshalb nutze ich fscrypt, sodass die erste PW-Eingabe erst in der grafischen Umgebung nötig wird. Auf meinem alten Go hatte ich mal LUKS mit pam_mount, bin da aber inzwischen auch auf fscrypt migriert, weil es nur 128 GB Speicher hat, was Partitionen ineffizient macht.

 

[SFFox]

Ich habe den Eingangspost gelesen, der benennt eine Lösung mit ungeordneten Theorien, was Ursache, Wirkung ist. Die "Lösung" die du bewirbst ist damit irgendwas zwischen, guter Tip (Discard bei dmcrypt aktivieren, wenn man das Risiko hinnehmen kann) bis gefährlich (jemand versucht sein kaputtes Array zu fixen).

Das hier soll kein Tutorial oder Tipp sein, sondern ist eine Zustandsbeschreibung mit allem, was ich bisher versucht habe dem Fehler auf den Grund zu gehen und mögliche Erklärungsversuche. Mehr ein aufmerksam machen auf potentielle Probleme.
Was ich mir wünsche ist Erklärungshilfe, weil ich an dem WARUM interessiert bin und es mein Wissen übersteigt. Die Daten sind safe, niemand ist angehalten Datenrettungshilfe zu leisten.
Das kann ich für Einsteiger im Thread noch mal deutlich kennzeichnen im Startbeitrag (done), aber ich vermute die Leute, die per Google in dieser Problematik landen, wissen das wahrscheinlich ungefähr einzuschätzen.

dmcrypt, mdadm, ATA/AHCI/NCMe nicht schon vorher Fehler geworfen haben, dann ist das Ganze extrem merkwürdig.

Ich versichere dir, dass es dazu keine Einträge gibt. Und ja, ich finde das Ganze auch merkwürdig.

Ich habe noch einen SATA Anschluss frei, wo ich das ganze noch mal mit einer gänzlich unproduktiven alten Crucial M4 64GB SATA SSD nachstellen werde, aber dazu fehlt mir gerade ein bisschen die Zeit und Lust.

Und CurveOptimizer.. Mein Desktop ist damit auch stabil, bis er es aller Tage nicht ist. Trotz memtest, furmark, ng-stress über Stunden.

Ja, ist n schwieriges Thema bzgl. Verlässlichkeit. Die Hardware ist aber hand-me-down von meinem Desktop und lief dort in verschiedenen Einsatzszenarien seit mindestens über einem Jahr Absturz-frei und Fehler-frei. Wenn ich große Zweifel hätte würde ich das auch noch mal auf Stock Settings setzen. Aber wie gesagt, der Fehler ist reproduzierbar gewesen auf genau diesem Mountpoint mit den selben Voraussetzungen während alle anderen Mounts/Laufwerke es problemlos tun.