neuhalfen.name

A random collection of posts

Memtest Am Lebenden Kernel

Permalink

In meinem Keller steht ein Rechner. Auf diesem Rechner sind alle meine Dokumente, E-Mails und Projekte der letzten zehn Jahre gespeichert. Der Rechner läuft 24/7, bis jetzt wahrscheinlich mehr oder weniger fehlerfrei.

Die Daten sind auf zwei gespiegelten SATA Festplatten untergebracht. Das verwendete Dateisystem sichert jeden Block mit Checksummen gegen Übertragungsfehler oder von den Platten unerkannte Lesefehler ab. Von den Daten werden regelmäßig Snapshots angefertigt, wichtige Daten werden zusätzlich auf meinem Laptop gespeichert. Alles in allem sollte mich das vor allzu gravierenden Datenverlusten schützen.

Ansonsten ist der Rechner ein “Consumer-Grade” Rechner: Consumer Chipsatz, Consumer Prozessor (AMD X2) und normaler, nicht ECC fähiger DDR2 Arbeitsspeicher.

Defekter Speicher

Über den Daumen gepeilt habe ich in den letzten Jahren schon drei oder vier mal defekte RAM-Chips austauschen müssen. Dass überhaupt Arbeitsspeicher defekt war, habe ich auch nur durch zunehmende Abstürze feststellen können. Bis jetzt habe ich zum Glück auch noch keine Daten endgültig verloren. Bei einem Verdacht auf defekte Speicher musste der Rechner heruntergefahren werden und über Nacht mit einem Speichertest traktiert werden.

Neben defekten Chips ist bei einem 24/7 laufenden Rechner auch das Thema kosmische Strahlung relevant. Ein durch ein Alphateilchen gekipptes Bit ist durch einen nachgelagerten Speichertest jedoch weder erkenn- noch korrigierbar.

Wünschenswert wäre ein kontinuierlicher Speichertest, der zumindest Hardwarefehler erkennt. Mit kontinuierlich meine ich, dass jede Speicherzelle des Arbeitsspeichers periodisch auf Zuverlässigkeit überprüft wird, und zwar während der Rechner seiner eigentlichen Arbeit nachkommt. Die Erkennung und eventuelle Korrektur gekippter Bits wäre ebenfalls wünschenswert.

Dedizierter Speichertest mit eigenem BS

Aktuell wird Arbeitsspeicher mit speziellen Programmen wie Memtest getestet. Dabei wird der Speichertest als einziges Programm auf dem Rechner ausgeführt. Dieses Verfahren bringt Vorteile, da z.B. der komplette Arbeitsspeicher direkt ansprechbar ist und Beeinflussungen durch andere Programme oder ein Betriebssystem ausgeschlossen werden.

Der Nachteil bei diesem Vorgehen ist, dass der Rechner wärend des Tests nicht für seinen eigentlichen Einsatz verwendbar ist. Weiterhin muss man dann hoffen, dass das reguläre Betriebssystem den Speicher (controller) nicht anders konfiguriert hat als der Speichertest.

Kontinuierlicher Speichertest

Grob zusammengefasst kann man unterscheiden zwischen

  1. unzuverlässige Hardware und
  2. gekippten Bits durch externe Einflüsse wie Alphastrahlung

Unzuverlässige Hardware kann durch das Beschreiben mit einem bekannten Bitmuster erkannt werden. Das Bitmuster wird geschrieben und ausgelesen. Liest man ein anderes Muster als man geschrieben hat, geht man von einem Speicherfehler aus.

Gekippte Bits im regulär durch das BS verwendeten Speicher lassen sich nur durch Checksummen erkennen und korrigieren, da sich keine Testmuster, sondern Live-Daten im Speicher befinden.

Die Idee ist nun, dass man den Arbeitsspeicher im laufenden Betrieb auf unzuverlässige Hardware prüft. Die “großen” Betriebssysteme wie Linux und Solaris können auf einmal als defekt erkannten Speicher reagieren (Stichwort: nicht korrigierbare ECC-Fehler). Es fehlt nur noch die entsprechende Diagnose-Komponente.

Hier beschränke ich mich auf den ersten Fall: Unzuverlässige Hardware.

Implementierung

Die Implementierung eines solchen Speichertests muss folgendes leisten:

  • Für eine gegebene Speicherseite erkennen, ob diese defekt ist oder nicht.
  • Jede Seite des Arbeitsspeichers “oft genug” überprüfen, wobei sich der Wert für “oft genug” aus einer Abwägung zwischen zuverlässiger Erkennung und Leistungseinbußen ergibt.

Als Einschränkung gilt: Für einen produktiven Einsatz darf dabei keine allzu große Performance-Einbuße entstehen.

Eine mögliche Umsetzung würde an mehreren Stellen im Kernel ansetzen:

  • Ein “Testscheduler” führt eine Liste aller noch zu prüfenden Seiten und initiiert die Prüfung der Seiten.
  • Die Speicherverwaltung muss auf Anfrage bestimmte Seiten für den Test bereitstellen können.
  • Eine Testkomponente führt den Test durch und meldet das Ergebnis.

Um eine zu große Beeinträchtigung der Systemleistung zu verhindern muss der Scheduler sowohl die Prozessor- als auch die Speicherlast beachten. Denkbar ist ein kostenbasierter Scheduler, der den Preis einer Prüfung (nicht verwendete Seite und geringe Systemlast vs. Seite eines aktiven Prozesses) gegen den Wert der Prüfung (Dauer seit der letzten Prüfung) aufrechnet. Weitere Möglichkeiten zur Verbesserung des Laufzeitverhaltens lassen sich eventuell durch eine Unterstützung für NUMA Architekturen/Systeme mit mehreren Pfaden für den Speicherzugriff erreichen.

Virtualisierung / Hypervisor

Ein weiterer Ansatz zur Implementierung ist die Integration in einen Hypervisor. Hier ist entweder eine direkte Integration oder eine spezielle Gast-Domäne denkbar.

Fazit

Wäre mein Server mit seiner Konfiguration ein Ausnahmefall, würde sich Forschung in diese Richtung nicht anbieten. In der Realität ist diese Konfiguration jedoch die Basis tausender (Web)server. Der Einsatz von ähnlichen Rechnern erstreckt sich mittlerweile vom High-End Server bis hin zu Net-Top. Das ehemalige PC-Betriebssystem Linux wird mittlerweile auf Netzwerkgeräten (OpenWrt) und Handys (openmoko) eingesetzt. Hier bietet sich ein ähnliches Bild: möglichst geringe Hardwarekosten bei permanentem Einsatz.

Unter diesem Aspekt halte ich diesen Ansatz durchaus für relevant und zukunftsträchtig. Mal sehen, was sich daraus machen lässt.

Weitere Anwendungsmöglichkeiten

  • Überprüfung von TEXT-Segmenten auf Modifikationen
  • Fehlerkorrektur durch Prüfsummen