Fehlerhafte Festplattenfehler und Zuverlässigkeit des Linux-Austauschs

Meines Wissens nach implementieren Festplatten und SSDs einige grundlegende Fehlerkorrekturen im Laufwerk, und die meisten RAID-Konfigurationen, z. B. mdadm, hängen davon ab, um zu entscheiden, wann ein Laufwerk einen Fehler nicht behoben hat und offline geschaltet werden muss. Dies hängt jedoch davon ab, dass der Speicher in seiner Fehlerdiagnose 100% genau ist. Dies ist nicht der Fall, und eine häufig verwendete Konfiguration wie ein RAID-1-Spiegel mit zwei Laufwerken ist anfällig: Angenommen, einige Bits auf einem Laufwerk sind stillschweigend beschädigt und das Laufwerk meldet keinen Lesefehler. Daher implementieren Dateisysteme wie btrfs und ZFS ihre eigenen Prüfsummen, um fehlerhaften Firmware-Laufwerken, fehlerhaften SATA-Kabeln usw. nicht zu vertrauen.

In ähnlicher Weise kann RAM auch Zuverlässigkeitsprobleme aufweisen, und daher haben wir ECC-RAM, um dieses Problem zu lösen.

Meine Frage lautet : Wie kann die Linux-Auslagerungsdatei kanonisch vor stiller Beschädigung / Bitfäule geschützt werden, die nicht von der Laufwerksfirmware in einer Konfiguration mit zwei Festplatten (dh unter Verwendung von Hauptkernel-Treibern) erfasst wird? Es scheint mir, dass eine Konfiguration, die hier keinen End-to-End-Schutz bietet (wie die von btrfs), den durch ECC RAM verursachten Seelenfrieden etwas negiert. Ich kann mir aber keinen guten Weg vorstellen:

• btrfs unterstützt Swapfiles überhaupt nicht. Sie können ein Loop-Gerät aus einer btrfs-Datei einrichten und einen Swap durchführen. Das hat aber Probleme:
  • Zufällige Schreibvorgänge funktionieren nicht gut: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • Der dortige Vorschlag, das Kopieren beim Schreiben zu deaktivieren, deaktiviert auch die Prüfsumme - und macht damit den ganzen Punkt dieser Übung zunichte. Sie gehen davon aus, dass die Datendatei über einen eigenen internen Schutz verfügt.
• ZFS unter Linux ermöglicht die Verwendung eines ZVOL als Swap, was meiner Meinung nach funktionieren könnte: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap. Nach meiner Lektüre erfordert ZFS jedoch normalerweise Speicherplatz und bringt ihn zum Swap -nur Anwendung klingt wie einige Arbeit, um es herauszufinden. Ich denke, das ist nicht meine erste Wahl. Warum Sie ein Out-of-Tree-Kernelmodul verwenden müssten, um einen zuverlässigen Swap zu erhalten, ist mir ein Rätsel - sicherlich gibt es heutzutage eine Möglichkeit, dies mit den meisten modernen Linux-Distributionen / -Kerneln zu erreichen?
• Es gab tatsächlich einen Thread auf einer Linux-Kernel-Mailingliste mit Patches, um Prüfsummen im Speichermanager selbst zu aktivieren, genau aus den Gründen, die ich in dieser Frage diskutiere: http://thread.gmane.org/gmane.linux.kernel/989246 - Leider ist der Patch, soweit ich das beurteilen kann, gestorben und hat ihn aus mir unbekannten Gründen nie stromaufwärts geschafft. Schade, es klang wie eine nette Funktion. Wenn Sie dagegen ein RAID-1 austauschen - wenn die Beschädigung die Reparaturfähigkeit der Prüfsumme übersteigt, möchten Sie, dass der Speichermanager versucht, vom anderen Laufwerk zu lesen, bevor er in Panik gerät oder was auch immer wahrscheinlich außerhalb des Bereichs, den ein Speichermanager tun sollte.

In Summe:

• RAM hat ECC, um Fehler zu korrigieren
• Dateien im permanenten Speicher haben btrfs, um Fehler zu korrigieren
• Tausch hat ??? <--- das ist meine Frage

Wir vertrauen auf die Integrität der vom Swap abgerufenen Daten, da die Speicherhardware Prüfsummen, CRCs usw. enthält.

In einem der obigen Kommentare sagen Sie:

stimmt, aber es schützt nicht vor Bitflips außerhalb der Festplatte

"Es" bedeutet hier die Prüfsummen der Festplatte.

Das stimmt, aber SATA verwendet 32-Bit-CRCs für Befehle und Daten. Somit besteht eine Wahrscheinlichkeit von 1 zu 4 Milliarden, dass Daten zwischen der Festplatte und dem SATA-Controller nicht nachweisbar beschädigt werden. Das bedeutet, dass eine kontinuierliche Fehlerquelle so oft wie alle übertragenen 125 MiB einen Fehler verursachen könnte, aber eine seltene, zufällige Fehlerquelle wie kosmische Strahlung würde mit einer verschwindend geringen Rate nicht nachweisbare Fehler verursachen.

Beachten Sie auch, dass die Leistung aufgrund der hohen Anzahl erkannter Fehler, die erneut übertragen werden müssen, schrecklich ist , wenn Sie eine Quelle haben, die einen unerkannten Fehler mit einer Rate nahe einer pro 125 MiB verursacht. Durch Überwachung und Protokollierung werden Sie wahrscheinlich rechtzeitig auf das Problem aufmerksam gemacht, um unerkannte Beschädigungen zu vermeiden.

Bei den Prüfsummen des Speichermediums werden auf jeder SATA-Festplatte (und davor auf der PATA-Festplatte) Prüfsummen pro Sektor verwendet. Eines der charakteristischen Merkmale von "Enterprise" -Festplatten sind größere Sektoren, die durch zusätzliche Datenintegritätsfunktionen geschützt sind , wodurch die Wahrscheinlichkeit eines nicht erkannten Fehlers erheblich verringert wird.

Ohne solche Maßnahmen hätte der Ersatzsektorpool auf jeder Festplatte keinen Sinn : Die Festplatte selbst könnte keinen fehlerhaften Sektor erkennen, sodass niemals neue Sektoren ausgetauscht werden könnten.

In einem anderen Kommentar fragen Sie:

Wenn SATA so vertrauenswürdig ist, warum gibt es Prüfsummen-Dateisysteme wie ZFS, btrfs, ReFS?

Im Allgemeinen bitten wir Swap nicht, Daten langfristig zu speichern. Die Begrenzung des Swap-Speichers ist die Betriebszeit des Systems , und die meisten Daten im Swap halten nicht annähernd so lange, da die meisten Daten, die das virtuelle Speichersystem Ihres Systems durchlaufen, zu viel kürzeren Prozessen gehören.

Darüber hinaus sind die Betriebszeiten im Laufe der Jahre im Allgemeinen kürzer geworden, was mit der zunehmenden Häufigkeit von Kernel und libcUpdates, Virtualisierung, Cloud-Architekturen usw. zu tun hat .

Darüber hinaus werden die meisten Daten in Swap in einem gut verwalteten System von Natur aus nicht mehr verwendet, da es sich nicht um einen Hauptspeicher handelt. In einem solchen System landen nur Seiten , die das Programm nicht oft verwendet, wenn überhaupt. Dies ist häufiger als Sie vielleicht vermuten. Die meisten dynamischen Bibliotheken, die Ihre Programme verknüpfen, enthalten Routinen, die Ihr Programm nicht verwendet, die jedoch vom dynamischen Linker in den Arbeitsspeicher geladen werden mussten . Wenn das OS sieht , dass Sie nicht alle Programmtext in der Bibliothek verwenden, tauscht sie es aus, für Code und Daten Platz zu machen , dass Ihre Programme sind verwenden. Wenn solche ausgelagerten Speicherseiten beschädigt sind, wer würde es jemals wissen?

Vergleichen Sie dies mit ZFS, bei dem wir erwarten, dass die Daten dauerhaft und dauerhaft gespeichert werden, sodass sie nicht nur über die aktuelle Betriebszeit des Systems hinausgehen, sondern auch über die Lebensdauer der einzelnen Speichergeräte, aus denen das Speichersystem besteht. ZFS und dergleichen lösen ein Problem mit einer Zeitskala, die ungefähr zwei Größenordnungen länger ist als das durch Swap gelöste Problem. Wir haben daher viel höhere Anforderungen an die Korruptionserkennung für ZFS als für Linux-Swap.

ZFS und dergleichen unterscheiden sich hier in einem anderen wichtigen Punkt vom Swap: Wir RAID-Swap-Dateisysteme nicht zusammen. Wenn auf einem Computer mehrere Swap-Geräte verwendet werden, handelt es sich um ein JBOD- Schema, das RAID-0 oder höher nicht ähnelt. (z. B. das verkettete Swap-Dateischema von macOS , Linux swaponusw.) Da die Swap-Geräte unabhängig und nicht wie bei RAID voneinander abhängig sind, ist keine umfangreiche Prüfsumme erforderlich, da beim Ersetzen eines Swap-Geräts keine anderen voneinander abhängigen Swap-Geräte gesucht werden müssen die Daten, die auf dem Ersatzgerät gespeichert werden sollen. In ZFS-Begriffen tauschen wir Geräte nicht gegen redundante Kopien auf anderen Speichergeräten aus.

All dies bedeutet, dass Sie ein zuverlässiges Swap-Gerät verwenden müssen. Ich habe einmal ein externes USB-Festplattengehäuse für 20 US-Dollar verwendet, um einen angeschlagenen ZFS-Pool zu retten, nur um festzustellen, dass das Gehäuse selbst unzuverlässig war und eigene Fehler in den Prozess einbrachte. Die starke Prüfsumme von ZFS hat mich hier gerettet. Mit einer solchen unbekümmerten Behandlung von Speichermedien mit einer Auslagerungsdatei kommt man nicht durch. Wenn das Swap-Gerät im Sterben liegt und sich damit dem schlimmsten Fall nähert, in dem alle 125 übertragenen MiB ein nicht nachweisbarer Fehler auftreten kann, müssen Sie es einfach so schnell wie möglich ersetzen.

Das allgemeine Gefühl der Paranoia in dieser Frage geht auf ein Beispiel des Problems der byzantinischen Generäle zurück . Lesen Sie darüber nach, überlegen Sie sich das Datum von 1982 in der wissenschaftlichen Arbeit, in der das Problem der Informatik beschrieben wird, und entscheiden Sie dann, ob Sie 2019 neue Gedanken haben, um dieses Problem zu ergänzen. Und wenn nicht, dann vielleicht werden Sie nur verwenden die Technologie von drei Jahrzehnten von CS entwickelt , um Absolventen , die alle wissen um die byzantinischen Generäle Problem.

Dies ist ein ausgetretener Boden. Sie können wahrscheinlich keine Idee, keinen Einwand oder keine Lösung finden, die in den Fachzeitschriften für Informatik noch nicht zu Tode diskutiert wurde.

SATA ist sicherlich nicht absolut zuverlässig, aber wenn Sie nicht in die Wissenschaft oder in eines der Kernel-Entwicklungsteams eintreten, sind Sie nicht in der Lage, den Stand der Technik hier wesentlich zu verbessern. Diese Probleme sind bereits in der Hand, wie Sie bereits bemerkt haben: ZFS, btrfs, ReFS ... Als Betriebssystembenutzer müssen Sie einfach darauf vertrauen, dass die Entwickler des Betriebssystems diese Probleme für Sie lösen, da sie es auch wissen über die byzantinischen Generäle.

Es ist derzeit nicht praktisch , Ihre Auslagerungsdatei auf ZFS oder Btrfs zu legen. Wenn Sie dies jedoch nicht beruhigt, können Sie sie zumindest auf xfs oder ext4 ablegen. Das wäre besser als die Verwendung einer dedizierten Swap-Partition.

dm-Integrität

Siehe: Dokumentation / Geräte-Mapper / dm-Integrität.txt

dm-integritywird normalerweise im Journalmodus verwendet. Im Falle eines Austauschs können Sie auf das Journal verzichten. Dies könnte den Leistungsaufwand erheblich senken. Ich bin nicht sicher, ob Sie die Swap-Over-Integrity-Partition bei jedem Start neu formatieren müssen, um Fehler nach einem unsauberen Herunterfahren zu vermeiden.

In der ersten Ankündigung vondm-integrity gibt der Autor stattdessen eine Präferenz für "Datenintegritätsschutz auf höherer Ebene" an. Im Falle eines Austauschs würde dies die Möglichkeit eröffnen, die Prüfsummen im RAM zu speichern. Diese Option würde jedoch sowohl nicht triviale Änderungen am aktuellen Auslagerungscode erfordern als auch die Speichernutzung erhöhen. (Die aktuellen Codespuren werden effizient über Extents ausgetauscht, nicht über einzelne Seiten / Sektoren.)

DIF / DIX?

Die DIX-Unterstützung wurde von Oracle in Linux 2.6.27 (2008) hinzugefügt .

Bietet die Verwendung von DIX End-to-End-Integrität?

Sie können Ihren Händler konsultieren. Ich weiß nicht, wie Sie sagen können, ob sie darüber lügen.

DIX ist erforderlich, um Daten im Flug zwischen dem Betriebssystem und dem HBA zu schützen .

DIF allein erhöht den Schutz für Daten im Flug zwischen dem HBA und dem Speichergerät . (Siehe auch: Darstellung mit einigen Zahlen zum Unterschied der Fehlerraten ).

Gerade weil die Prüfsumme im Schutzfeld standardisiert ist, ist es technisch möglich DIX Befehle zu implementieren , ohne die Bereitstellung jeden Schutz für ruhende Daten. Lassen Sie einfach den HBA (oder das Speichergerät) die Prüfsumme zum Zeitpunkt des Lesens neu generieren. Dieser Ausblick wurde durch das ursprüngliche DIX-Projekt deutlich gemacht.

• DIF / DIX sind orthogonal zu logischen Blockprüfsummen
  • Wir lieben dich immer noch, btrfs!
  • Logische Blockprüfsummenfehler werden zur Erkennung beschädigter Daten verwendet
  • Die Erkennung erfolgt zum Zeitpunkt des LESENS
  • ... was Monate später sein könnte, geht der ursprüngliche Puffer verloren
  • Redundante Kopien können auch fehlerhaft sein, wenn der ursprüngliche Puffer verstümmelt wurde
• Bei DIF / DIX geht es darum , Korruption proaktiv zu verhindern
  • Verhindern, dass fehlerhafte Daten überhaupt auf der Festplatte gespeichert werden
  • ... und sich über Probleme informieren, bevor der ursprüngliche Puffer aus dem Speicher gelöscht wird

- lpc08-data-integrity.pdf von oss.oracle.com

In einem ihrer frühen Beiträge zu DIX wird die Möglichkeit erwähnt, DIX zwischen Betriebssystem und HBA zu verwenden, auch wenn das Laufwerk DIF nicht unterstützt.

Eine vollständige Verlogenheit ist in "Unternehmens" -Kontexten, in denen DIX derzeit verwendet wird, relativ unwahrscheinlich. Leute würden es bemerken. Außerdem basierte DIF auf vorhandener Hardware, die mit 520-Byte-Sektoren formatiert werden konnte. Das Protokoll für die Verwendung von DIF erfordert angeblich, dass Sie zuerst das Laufwerk neu formatieren, siehe z sg_format. B. den Befehl.

Wahrscheinlicher ist eine Implementierung, die nicht dem wahren End-to-End-Prinzip folgt . Als ein Beispiel wird ein Anbieter genannt, der eine schwächere Prüfsummenoption für DIX unterstützt, um CPU-Zyklen zu speichern, die dann weiter unten im Stapel durch eine stärkere Prüfsumme ersetzt wird. Dies ist nützlich, aber kein vollständiger End-to-End-Schutz.

Alternativ könnte ein Betriebssystem seine eigenen Prüfsummen generieren und diese im Anwendungs-Tag-Bereich speichern. Dies wird jedoch unter dem aktuellen Linux (v4.20) nicht unterstützt . Der 2014 verfasste Kommentar deutet darauf hin, dass dies möglicherweise darauf zurückzuführen ist, dass "nur sehr wenige Speichergeräte die Verwendung des Anwendungs-Tag-Bereichs tatsächlich zulassen". (Ich bin nicht sicher, ob sich dies auf das Speichergerät selbst, den HBA oder beides bezieht).

Welche DIX-Geräte sind für Linux verfügbar?

Die Trennung der Daten- und Integritätsmetadatenpuffer sowie die Auswahl in Prüfsummen wird als Data Integrity Extensions [DIX] bezeichnet. Da diese Erweiterungen nicht in den Geltungsbereich der Protokollkörper (T10, T13) fallen, versuchen Oracle und seine Partner, sie innerhalb der Storage Networking Industry Association zu standardisieren.

- v4.20 / Dokumentation / Block / Datenintegrität.txt

Wikipedia sagt mir, dass DIF in NVMe 1.2.1 standardisiert ist. Für SCSI-HBAs scheint es ein bisschen schwierig zu sein, dies zu bestimmen, wenn wir keinen Standard haben, auf den wir verweisen können. Im Moment ist es vielleicht am genauesten, über die "Linux DIX" -Unterstützung zu sprechen :-). Es sind Geräte verfügbar:

SCSI T10 DIF / DIX [sic] wird in Red Hat Enterprise Linux 7.4 vollständig unterstützt, vorausgesetzt, der Hardwareanbieter hat es qualifiziert und bietet vollständige Unterstützung für die jeweilige HBA- und Speicherarray-Konfiguration. DIF / DIX wird in anderen Konfigurationen nicht unterstützt, es wird nicht für die Verwendung auf dem Startgerät unterstützt und es wird nicht für virtualisierte Gäste unterstützt.

Derzeit bieten die folgenden Anbieter diese Unterstützung an ...

- RHEL 7.5 Versionshinweise, Kapitel 16. Lagerung

Die gesamte in den RHEL 7.5-Versionshinweisen erwähnte Hardware ist Fibre Channel.

Ich kenne diesen Markt nicht. Es hört sich so an, als ob DIX in Zukunft auf Servern allgemeiner verfügbar sein könnte. Ich kenne keinen Grund, warum es für Consumer-SATA-Festplatten verfügbar werden würde - soweit ich weiß, gibt es nicht einmal einen De-facto-Standard für das Befehlsformat. Ich werde gespannt sein, ob es auf NVMe breiter verfügbar wird.

Tausch hat ??? <--- das ist meine Frage

Swap ist unter Linux immer noch nicht geschützt (siehe jedoch UPD).

Natürlich gibt es ZFS unter Linux, das ein Swap-Speicher sein kann, aber unter bestimmten Umständen gibt es immer noch eine Sperrung - wodurch diese Option effektiv widerrufen wird.

Btrfs kann Swap-Dateien immer noch nicht verarbeiten . Sie erwähnen die mögliche Verwendung von Loopback, obwohl festgestellt wird, dass die Leistung schlecht ist. Es gibt einen unklaren Hinweis darauf, dass Linux 5 es endlich haben könnte (?)…

Patches zum Schutz des konventionellen Swaps selbst mit Prüfsummen schafften es nicht in den Mainstream.

Alles in allem also: Nein. Linux hat dort noch eine Lücke.

UPD. : Wie @ sourcejedi hervorhebt , gibt es ein Tool wie dm-integrity. Der Linux-Kernel hat seit Version 4.12 das Ziel des Geräte-Mappers erhalten, das zur Bereitstellung von Prüfsummen für allgemeine Blockgeräte verwendet werden kann, und solche, die für den Austausch bestimmt sind, sind keine Ausnahme. Das Tooling ist nicht allgemein in großen Distributionen integriert und die meisten von ihnen haben keine Unterstützung im udev-Subsystem, aber irgendwann sollte sich dies ändern. In Verbindung mit einem Redundanzanbieter, z. B. auf einem MD, auch bekannt als Linux Software RAID, sollte es nicht nur möglich sein, Bit Rot zu erkennen, sondern auch E / A-Anforderungen an fehlerfreie Daten umzuleiten, da die dm-Integrität darauf hinweist, dass ein Fehler vorliegt Problem und MD sollte damit umgehen.

Ich glaube nicht, dass es einen "kanonischen" Weg gibt, daher ist das Folgende meine persönliche Meinung.

Nachdem ich den Fortschritt von btrfs aus der Sicht eines potenziellen Benutzers überwacht habe, muss ich sagen, dass es für mich immer noch irgendwie dunkel ist. Es gibt Funktionen, die ausgereift und produktionsbereit sind, und es gibt Funktionen, die scheinbar unausgereift und gefährlich zu verwenden sind.

Persönlich habe ich nicht die Zeit zu entscheiden, welche Funktion verwendet werden soll und welche nicht. Lassen Sie die Zeit weg, die ich benötigen würde, um herauszufinden, wie diese Funktionen ein- oder ausgeschaltet werden.

Im Gegensatz dazu ist ZFS absolut solide und ausgereift (IMHO). Um Ihre Frage zu beantworten, würde ich ZFS verwenden (es verbraucht übrigens nicht viel Speicher - siehe unten).

Aber für Sie ist btrfs möglicherweise die richtige Wahl, da Sie es bereits verwenden (wenn ich Sie richtig verstanden habe), und einer der obigen Kommentare zeigt, wie Sie es für den Tausch verwenden.

Durch Zufall habe ich in den letzten Tagen einige Linux-Server auf ZFS gestellt, jedes Mal einschließlich des Root-Dateisystems und des Swaps. Bevor ich das getan habe, habe ich sehr gründlich recherchiert, was mich mehrere Tage gekostet hat. Eine kurze Zusammenfassung dessen, was ich gelernt habe:

Speicherverbrauch von ZFS

Es gibt ein häufiges Missverständnis hinsichtlich des Speicherverbrauchs von ZFS. ZFS verbraucht im Allgemeinen nicht viel Speicher. Tatsächlich läuft es mit TBs Speicher auf Computern mit 2 GB RAM. Nur wenn Sie die Deduplizierung verwenden (standardmäßig deaktiviert), benötigt sie sehr viel RAM.

Erkennung / Korrektur von Hardwarefehlern

Ob SATA-, PATA-, RAID- oder andere Fehlererkennungs- / Korrekturmechanismen für die Datenintegrität ausreichen, ist ein Thema, das an allen Stellen im Netz endlose Diskussionen und sogar Flammenkriege hervorruft. Theoretisch sollte ein Hardwarespeichergerät jeden aufgetretenen Fehler melden (und möglicherweise korrigieren), und die Datenübertragungshardware auf allen Ebenen (Chipsatz, Speicher usw.) sollte dies ebenfalls tun.

Nun, sie tun es nicht in allen Fällen oder sie reagieren überraschend auf Fehler. Nehmen wir als Beispiel eine typische RAID5-Konfiguration. Wenn eine Festplatte ein Problem hat, meldet sie dies normalerweise an das RAID, das wiederum die zu lesenden Daten von den anderen Festplatten erstellt und weiterleitet, sie aber auch auf die fehlerhafte Festplatte zurückschreibt (was wiederum wahrscheinlich die Daten neu zuordnet) Sektor vor dem Schreiben der Daten); Wenn dieselbe Festplatte zu viele Fehler meldet, wird sie vom RAID offline geschaltet und informiert den Administrator (sofern ordnungsgemäß konfiguriert).

So weit, so gut, aber es gibt Fälle, in denen fehlerhafte Daten von einer Festplatte übertragen werden, ohne dass die Festplatte einen Fehler meldet (siehe nächster Abschnitt). Die meisten RAIDs können diese Situation anhand der Paritätsinformationen erkennen, aber ihre Reaktion ist dumm: Anstatt den Fehler zu melden und die Weitergabe der Daten zu verhindern, berechnen sie die Parität einfach anhand der fehlerhaften Daten neu und schreiben die neue Parität in die jeweilige Festplatte, wodurch die fehlerhaften Daten für immer als korrekt markiert werden.

Ist das ein vernünftiges Verhalten? Soweit ich weiß, funktionieren die meisten Hardware-RAID5-Controller und sogar das md-RAID von Linux auf diese Weise.

Ich weiß nichts über die Fehlerkorrektur von btrfs, aber Sie sollten die Dokumente eventuell noch einmal sorgfältig lesen, insbesondere wenn Sie das RAID von btrfs verwenden.

Stille Bitfäule

Trotz aller Flammenkriege und (pseudo-) wissenschaftlichen Diskussionen: Die Realität unterscheidet sich größtenteils von der Theorie, und stille Bitfäule tritt definitiv auf, obwohl die Theorie das Gegenteil aussagen könnte (stille Botfäule bedeutet normalerweise, dass Daten auf dem Hardwarespeicher beschädigt werden, ohne dass das Speichergerät eine meldet Fehler beim Lesen dieser Daten, aber ich werde dieser Definition überall im Übertragungspfad Flip-Bits hinzufügen.

Dass dies geschieht, ist nicht meine persönliche Meinung: Zumindest haben Google, Amazon und CERN detaillierte Whitepaper veröffentlicht, die genau dieses Thema abdecken. Die Beiträge stehen kostenlos zum öffentlichen Download zur Verfügung. Sie haben systematische Experimente mit mehreren Millionen Festplatten und Hunderttausenden von Servern / Speichergeräten durchgeführt, entweder weil sie Probleme mit unerkannter Datenbeschädigung hatten oder weil sie wissen wollten, was zu tun ist, um dies zu verhindern, bevor es passierte.

Zusammenfassend lässt sich sagen, dass Daten in ihren Serverfarmen mit einer Rate beschädigt wurden, die deutlich höher war als die MTBF-Statistiken oder andere theoretische Erwartungen. Mit deutlich höher meine ich Größenordnungen.

Daher ist die stille Bitfäule, dh die unerkannte Datenbeschädigung an jedem Punkt des Übertragungspfads, ein echtes Problem.

Datenlebensdauer

Warren Young hat Recht, wenn er sagt, dass Swap-Daten eine kurze Lebensdauer haben. Aber ich möchte die folgende Überlegung hinzufügen: Nicht nur Daten (im Sinne von Dokumenten) werden ausgetauscht, sondern (vielleicht sogar noch wahrscheinlicher) Teile des Betriebssystems oder anderer laufender Software . Wenn ich einen MP3-Tausch habe, könnte ich mit einem Flip-Bit leben. Wenn (aufgrund einer extremen Situation) Teile meiner Produktions-httpd-Serversoftware ausgetauscht werden, kann ich auf keinen Fall mit einem Flip-Bit leben, das später zur Ausführung von beschädigtem Code führt, wenn er nicht erkannt wird.

Epilog

Für mich löst ZFS diese Probleme, oder genauer gesagt, es verschiebt sie von den Festplatten in den Speicher und reduziert dadurch die Wahrscheinlichkeit für stille Bitfäule um einige Größenordnungen. Wenn es richtig konfiguriert ist (dh Spiegel anstelle von RAID), bietet es außerdem eine saubere und vernünftige Fehlerkorrektur, die wie erwartet funktioniert und schließlich leicht zu verstehen ist.

Bitte beachten Sie jedoch, dass Sie niemals absolute Sicherheit erhalten. Persönlich vertraue ich meinem ECC-RAM mehr als meinen Festplatten und bin überzeugt, dass ZFS mit seinen End-to-End-Prüfsummen die Problemwahrscheinlichkeit um Größenordnungen reduziert. Ich würde jedoch niemals empfehlen, ZFS ohne ECC-RAM zu verwenden.

Haftungsausschluss: Ich bin in keiner Weise mit einem ZFS-Anbieter oder -Entwickler verbunden. Dies gilt für alle Varianten (Gabeln) von ZFS. Ich bin in den letzten Tagen einfach ein Fan davon geworden ...