Wenn das NAS oder der PC nach dem Einbau einer NVME-SSD einfriert

Zuletzt aktualisiert am 14. Januar 2023.

Oder: Wieso mir keine DRAMless-NVME-SSD bzw. keine Consumer-SSD von Western Digital mehr ins NAS kommt.

Synology NAS sind weit mehr als ein einfaches NAS. Durch das mächtige Betriebssystem DSM, Docker und den Virtual Maschine Manager kann man ein Synology NAS für immer mehr Server-Aufgaben nutzen. Um viele Dienste bereitstellen zu können, empfiehlt es sich, die die IO-Kapazitäten mittels eines SSD-Caches zu beschleunigen – aber hier ist Vorsicht geboten!

Vorweg: Die von mir genutzte WD SN550 NVME-SSD steht nicht auf der Synology Kompatibilitätsliste und ist eine Consumer-Grade-SSD. Das heißt, sie sollte ohnehin in keinem Umfeld, in dem wichtige Daten gespeichert werde verwendet werden. Auch als SSD-Cache sollte sie nicht verwendet werden.

Günstige NVME-SSD – oft empfohlen

Die SN550 SSD ist wohl eine der meistverkauftesten SSDs. Kein Wunder, ist sie auf dem Papier (und in der Regel auch in der Praxis) schnell und vergleichsweise günstig.

Es gibt sogar einige Empfehlungen, die SN550 aufgrund des günstigen Preises und der vergleichsweise langen Haltbarkeit von 600 TBW (Terabytes Written) für den Einsatz als SSD-Cache in NAS empfehlen.

Aber Vorsicht, ich kann davon nur Abraten, denn:

A) Es handelt sich um Consumer SSDs, die explizit nicht auf der Kompatibilitätsliste stehen.

B) Ich habe selbst die Erfahrung machen müssen, dass diese SSDs als Cache nicht nutzbar sind – Es droht Datenverlust!

Wieso nutze ich einen SSD-Cache?

Auf meinen Synology NAS laufen mittlerweile mehr als nur eine Handvoll Dienste. Von der privaten Photostation über Webserver, Storagenodes, Heimautomatisierung usw. Alle diese Dienste brauchen neben CPU und RAM durchaus auch IO-Kapazitäten, das heißt, sie schreiben und lesen von der Festplatte bzw. dem Raid-Volume des NAS.

Da Festplatten als mechanische Speichermedien vergleichsweise langsam sind und nur eine gewisse Anzahl an Input-Output-Operationen zeitgleich durchführen können (der Lesearm in der Festplatte muss tatsächlich manuell bewegt werden), bietet sich die Beschleunigung des Volumes und die Erhöhung der I/O-Kapazitäten mittels eines SSD-Caches an. Praktischerweise bietet Synology diese Funktionalität von Hausaus an.

Hintergrundinformation: So funktioniert der Synology SSD-Cache
Der SSD-Cache von Synology ist eigentlich ein durchdachtes System. 

Lesecache
Das NAS analysiert, welche Datenblöcke häufig gelesen und/oder geschrieben werden und kopiert diese im Falle eines Lesecaches auf das zusätzliche SSD-Volume und speichert in einer im RAM befindlichen "MAP" - quasi einer Zuordnung, welche Datenblöcke sich ebenfalls auf der SSD befinden ("Hot Data"). Diese Daten werden dann von der SSD gelesen, was wesentlich performanter ist, als von den HDDs zu lesen.
Die Daten sind hierbei aber immer redundant vorgehalten, also ebenfalls auf der HDD gespeichert.

Lese-Schreib-Cache
Anders ist das beim Lese-Schreib-Cache. Hier werden die SSDs (es müssen für einen Lese-Schreib-Cache mindestens 2 SSDs sein) quasi Teil des zu beschleunigenden Volumes. Es wird ebenfalls eine Map im RAM für die zu lesenden Daten erzeugt, aber sämtliche Schreibvorgänge werden zunächst auf dem schnellen SSD-Speicher durchgeführt und erst später nach und nach auf die HDDs übertragen.
Dieser Unterscheid ist wichtig, denn damit geht einher, dass beim Verlust des SSD-Speichers das gesamte beschleunigte Volume unwiderruflich zerstört werden kann (Stichwort: Korruptes Filesystem).

Quelle: https://global.download.synology.com/download/Document/Software/WhitePaper/Firmware/DSM/All/enu/Synology_SSD_Cache_White_Paper.pdf

Ich nutze in meinem Fall die Erweiterungskarte M2D18 in meinem DS3018xs-NAS um performante NVME-SSDs verwenden zu können.

Was ist das Problem mit den SN550-SSDs?

Das Problem bei den SN550-SSDs ist, dass diese sporadisch einfach einfrieren, vom System disconnected werden und nicht wieder aufwachen. Besonders fatal ist, dass dieser Umstand unter Last zunimmt und durch die Nutzung im Raid häufiger auftritt.
Das Ergebnis ist in letzter Konsequenz, dass im Falle des Einfrierens schon einer SSD das gesamte System nicht mehr reagiert und im schlimmsten Falle das gesamte Volume zerstört wird.

Ich habe mir durch genau diese Problematik mein ganzes Volume auf meinem NAS zerstört. Trotz tiefgreifender Reparaturversuche über die Konsole ist das Filesystem nicht mehr zu retten gewesen. Die Indizes im BTRFS waren zerstört, trotz mehrerer Backup-Superblocks ließ sich das FS nicht wiederherstellen.

In meiner Naivität habe ich das ganze mehrfach versucht. Das Ergebnis ist immer das Gleiche gewesen: Der SSD-Cache ist nach spätestens 24 Stunden abgestürzte, das NAS eingefroren und das Volume zerstört gewesen.
Es gibt auf jeden Fall massive Probleme mit der Nutzung der SNN550-SSDs im Raid – man muss natürlich fairerweise sagen, dass die SSDs dafür auch nicht gedacht sind.

Das Problem kann offenbar mehrere Ursachen haben, von defekter Hardware, über inkompatible Treiber, eine verbuggte Firmware und Hardwareinkompatibilitäten.
Es lässt sich für mich aber auf jeden Fall ein klarer Zusammenhang zwischen der auflaufenden IO-Last (und damit ggf. der Hitze und Kühlung?) herstellen:

Ich nutze die SSDs nun als eigenständiges Volume. Das läuft soweit stabil. Sobald ich aber über das DSM z.B. die Datenträgerbereinigung einschalte – ein sehr I/O-lastiger Prozess – kann ich die Minuten zählen, bis das NAS komplett einfriert.
Die Temperatur habe ich dabei im Blick, sie steigt laut Sensor nicht über 55 Grad. Es kann aber natürlich sein, dass die SSD an anderer Stelle viel heisser wird.

Eine Verbesserung hat übrigens durch das Update des DSM 6.x Systems des NAS auf DSM 7.x ergeben – wieso ist mir unbekannt.

Lösungsansätze

Probleme mit NVME-SSDs und insbesondere solchen ohne DRAM-Pufferpeicher sind gar nicht so selten:

https://www.tekbyte.net/fixing-nvme-ssd-problems-on-linux/

What does "nvme_core.default_ps_max_latency_us=0" mean?
 byu/satyamnoob inUbuntu
 https://esc.sh/blog/nvme-ssd-and-linux-freezing/

https://community.wd.com/t/linux-support-for-wd-black-nvme-2018/225446

https://unix.stackexchange.com/questions/612096/clarifying-nvme-apst-problems-for-linux

https://www.reddit.com/r/linuxquestions/comments/hz3z1e/new_nvme_ssd_causes_linux_to_freeze_not_windows/

Die Probleme mit exakt dieser SSD sind im Netz durchaus mehrfach dokumentiert.
Hier finden sich auch einzelne Lösungsansätze:

https://bugzilla.kernel.org/show_bug.cgi?id=208123

Fixed : WD SN550 was never detected on cold boot, would then be detected after sitting in BIOS for about 1 minute. Solution inside
 byu/MrLefitty inbuildapc
 https://community.wd.com/t/question-about-wd-blue-sn550/261204

https://community.wd.com/t/not-showing-in-bios-wd-blue-sn550-1tb-m-2-pcie-nvme-ssd/253764/3

https://community.wd.com/t/sn550-not-showing-in-bios-or-os/264223/7

https://community.wd.com/t/my-new-wd-blue-1tb-sata-ssd-freezes-my-comp-sporadically-while-gaming/259329/3

https://community.wd.com/t/wd-sn550-wont-let-me-boot-into-bios-or-windows/268740/5

-> Firmwareupdate der SSD

Ein zwischenzeitliches Firmwareupdate hat einzelnen Nutzern wohl geholfen, in meinem Fall hat es keine Abhilfe gebracht.

-> Überprüfung der APST-Einstellungen

-> Update des Betriebssystems

Ebenfalls eine Idee ist das Update des genutzten Betriebssystems (und/oder des BIOS!). In meinem Fall hat das Upgrade von DSM 6.x auf DSM 7.x eine signifikante Verbesserung gebracht. Der Fehler ist zwar nicht ganz behoben, tritt aber viel viel seltener auf.

Mein Workaround: Nutzung als Volume

Ich kann nur von mir sprechen, aber mein klares Learning ist, dass ich diese SSDs nie wieder als Cache einsetzen werde – ohnehin werde ich den nächsten Cache mit SATA-SSDs aufbauen und nicht mit NMVE-SSDs. Das ist zwar etwas langsamer, bietet aber noch immer deutlich mehr IOPS als eine HDD sowie geringere Latenzen und vor allem gibt es einen darüberliegenden Layer, der dafür sorgt, dass abgestürzte Geräte ausgeworfen werden und nicht das gesamte System einfrieren (siehe nächster Absatz).

Die SSDs, die ich ja nun aber habe, nutze ich derweil als eigenes Volume, hier sind sie bisher erstaunlich stabil – trotzdem ist natürlich ein regelmäßiges Backup das A und O.

Wieso nur bei NVME und nicht bei SATA SSD?

Die oben behandelte Problematik tritt NUR bei NVME-SSDs auf und nicht bei SATA-SSDs – wieso?
Das liegt an den unterschiedlichen Protokollen. Während SATA ein Protokoll ist, das auf einem höheren Layer ansetzt und ein Fehlerhaftes Laufwerk im Zweifel ausgeworfen wird, der Rest des Systems aber wie gewohnt weiter laufen kann, läuft NVME DIREKT über den PCI-Express-Bus des Systems. Hier gibt es keine zusätzliche Fehlertoleranz. Wenn die NVME-SSD einfriert, friert sofort das ganze System ein, da keine Daten mehr ausgetauscht werden können. Es gibt keine darüber liegende Instanz, die das hängende Laufwerk z.B. auswerfen könnte.

Fazit: Nie wieder DRAMless SSDs als SSD-Cache

Ich für meinen Teil habe meine Lektion gelernt, ich werde in Zukunft – vor allem in Systemen, auf denen wichtige Dienste laufen – trotz Backup NUR SSDs einsetzen, die auf der Synology-Kompatibilitätsliste stehen.
Zwar schiebe ich die Probleme primär auf eine fehlerhafte Firmware der Western-Digital-SSDs, aber es sind im Internet auch Probleme mit der ebenfalls DRAMless-SSD 980 von Samsung dokumentiert sind.

Es scheint hier noch Kinderkrankheiten bei der Firmware bei dieser recht neuen Technologie zu geben.

Trotzdem muss man fairerweise sagen, dass augenscheinlich auch Nutzer zu geben scheint, die mit dem gleichen Setup wie ich keine Probleme zu haben scheinen.