Wir vertrauen auf die Integrität der aus dem Austausch abgerufenen Daten, da die Speicherhardware hat Prüfsummen, CRCs und dergleichen.
In einem der obigen Kommentare sagen Sie:
wahr, aber es schützt nicht vor Bit-Flips außerhalb der Festplatte selbst
"Es" bedeutet hier die Prüfsummen der Festplatte.
Das stimmt, aber SATA verwendet 32-Bit-CRCs für Befehle und Daten. Daher besteht eine Wahrscheinlichkeit von 1 zu 4 Milliarden, dass Daten zwischen der Festplatte und dem SATA-Controller unbemerkt beschädigt werden. Das bedeutet, dass eine kontinuierliche Fehlerquelle alle 125 MiB übertragen einen Fehler verursachen könnte, aber eine seltene, zufällige Fehlerquelle wie kosmische Strahlung würde nicht erkennbare Fehler mit einer verschwindend geringen Rate verursachen.
Beachten Sie auch, dass die Leistung schrecklich sein wird, wenn Sie eine Quelle haben, die einen unentdeckten Fehler mit einer Rate von annähernd einem pro übertragenen 125 MiB verursacht wegen der hohen Zahl von entdeckten Fehler, die eine erneute Übertragung erfordern. Durch Überwachung und Protokollierung werden Sie wahrscheinlich rechtzeitig auf das Problem aufmerksam gemacht, um unentdeckte Beschädigungen zu vermeiden.
Was die Prüfsummen des Speichermediums betrifft, verwendet jede SATA- (und davor PATA-) Festplatte irgendeine Art von Prüfsummen pro Sektor. Eines der charakteristischen Merkmale von "Enterprise"-Festplatten sind größere Sektoren, die durch zusätzliche Datenintegritätsfunktionen geschützt sind, wodurch die Wahrscheinlichkeit eines unentdeckten Fehlers erheblich verringert wird.
Ohne solche Maßnahmen hätte der Reservesektorpool in jeder Festplatte keinen Sinn:Das Laufwerk selbst könnte einen fehlerhaften Sektor nicht erkennen und könnte daher niemals neue Sektoren einlagern.
In einem anderen Kommentar fragen Sie:
Wenn SATA so vertrauenswürdig ist, warum gibt es Dateisysteme mit Prüfsummen wie ZFS, btrfs, ReFS?
Im Allgemeinen bitten wir Swap nicht, Daten langfristig zu speichern. Die Grenze für den Auslagerungsspeicher ist die Betriebszeit des Systems, und die meisten Daten im Auslagerungsbereich halten nicht annähernd so lange, da die meisten Daten, die durch das virtuelle Speichersystem Ihres Systems gehen, zu viel kurzlebigeren Prozessen gehören.
Darüber hinaus sind die Betriebszeiten im Allgemeinen im Laufe der Jahre kürzer geworden, was mit der zunehmenden Häufigkeit von Kernel und libc zusammenhängt Updates, Virtualisierung, Cloud-Architekturen usw.
Darüber hinaus werden die meisten Daten im Swap-Bereich in einem gut verwalteten System von Natur aus nicht verwendet, da es sich nicht um einen Haupt-RAM handelt. In einem solchen System landen nur Seiten im Austausch, die das Programm, wenn überhaupt, nicht oft verwendet. 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 Betriebssystem erkennt, dass Sie nicht den gesamten Programmtext in der Bibliothek verwenden, tauscht es ihn aus und schafft Platz für Code und Daten, die Ihre Programme sind verwenden. Wenn solche ausgelagerten Speicherseiten beschädigt sind, wer würde das jemals erfahren?
Vergleichen Sie dies mit ZFS, wo wir erwarten, dass die Daten dauerhaft und dauerhaft gespeichert werden, sodass sie nicht nur über die aktuelle Betriebszeit des Systems hinaus bestehen, 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 Problem, das durch Swap gelöst wird. Wir haben daher viel höhere Anforderungen an die Erkennung von Beschädigungen für ZFS als für Linux-Swap.
ZFS und dergleichen unterscheiden sich hier in einer anderen wichtigen Weise von Swap:Wir RAID-Swap-Dateisysteme nicht zusammen. Wenn mehrere Auslagerungsgeräte auf einem einzelnen Computer verwendet werden, handelt es sich um ein JBOD-Schema, nicht wie RAID-0 oder höher. (z. B. das verkettete Auslagerungsdateischema von macOS, swapon von Linux usw.) Da die Auslagerungsgeräte unabhängig und nicht wie bei RAID voneinander abhängig sind, benötigen wir keine umfangreiche Prüfsummenbildung, da beim Ersetzen eines Auslagerungsgeräts nicht andere voneinander abhängige Auslagerungsgeräte nach den Daten gesucht werden müssen, die auf das Ersatzgerät übertragen werden sollen . In Bezug auf ZFS tauschen wir Geräte nicht von redundanten Kopien auf anderen Speichergeräten aus.
All dies bedeutet, dass Sie ein zuverlässiges Wechselgerät verwenden müssen. Ich habe einmal ein externes USB-HDD-Gehäuse im Wert von 20 US-Dollar verwendet, um einen maroden ZFS-Pool zu retten, nur um festzustellen, dass das Gehäuse selbst unzuverlässig war und eigene Fehler in den Prozess einführte. Die starke Prüfsummenbildung von ZFS hat mich hier gerettet. Mit einer so unbekümmerten Behandlung von Speichermedien kommt man mit einer Auslagerungsdatei nicht durch. Wenn das Auslagerungsgerät stirbt und sich dem schlimmsten Fall nähert, in dem es alle 125 MiB übertragen einen nicht erkennbaren Fehler einschleusen könnte, 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. Informieren Sie sich darüber, denken Sie über das Datum von 1982 in der wissenschaftlichen Arbeit nach, in der das Problem für die Welt der Informatik beschrieben wird, und entscheiden Sie dann, ob Sie 2019 neue Gedanken zu diesem Problem haben. Und wenn nicht, dann benutzen Sie es vielleicht einfach die Technologie, die von drei Jahrzehnten CS-Absolventen entwickelt wurde, die alle über das Problem der byzantinischen Generäle Bescheid wissen.
Das ist ausgetretener Boden. Sie können wahrscheinlich keine Idee, keinen Einwand oder keine Lösung finden, die nicht bereits in den Fachzeitschriften der Informatik zu Tode diskutiert wurde.
SATA ist sicherlich nicht absolut zuverlässig, aber wenn Sie nicht der Wissenschaft oder einem der Kernel-Entwicklungsteams beitreten, werden Sie nicht in der Lage sein, den Stand der Technik hier wesentlich zu verbessern. Diese Probleme sind bereits im Griff, wie Sie bereits bemerkt haben:ZFS, btrfs, ReFS ... Als Betriebssystembenutzer müssen Sie einfach darauf vertrauen, dass sich die Schöpfer des Betriebssystems um diese Probleme für Sie kümmern, weil sie es auch wissen über die byzantinischen Generäle.
Es ist derzeit nicht praktikabel, Ihre Auslagerungsdatei auf ZFS oder Btrfs zu legen, aber wenn Sie das Obige nicht beruhigt, können Sie sie zumindest auf xfs oder ext4 legen. Das wäre besser, als eine dedizierte Swap-Partition zu verwenden.
Tausch hat ??? <--- das ist meine Frage
Swap ist immer noch nicht geschützt unter Linux (aber siehe UPD).
Nun, natürlich gibt es ZFS unter Linux, das als Auslagerungsspeicher fungieren kann, aber unter bestimmten Umständen gibt es immer noch eine Sperre – wodurch diese Option effektiv widerrufen wird.
Btrfs kann immer noch nicht mit Auslagerungsdateien umgehen. Sie erwähnen die mögliche Verwendung von Loopback, obwohl festgestellt wird, dass es eine schlechte Leistung hat. Es gibt einen unklaren Hinweis darauf, dass Linux 5 es endlich (?) haben könnte…
Patches zum Schutz herkömmlicher Swaps selbst mit Prüfsummen haben es nicht bis zum Mainstream geschafft.
Also alles in allem:nein. Da hat Linux noch eine Lücke.
UPD. :Wie @sourcejedi darauf hinweist, gibt es ein Tool wie dm-integrity. Der Linux-Kernel hat seit Version 4.12 das Ziel des Device-Mapper erhalten, das zum Bereitstellen von Prüfsummen für alle allgemeinen Blockgeräte verwendet werden kann, und diejenigen, die zum Austauschen bestimmt sind, sind keine Ausnahme. Das Tooling ist nicht allgemein in große Distributionen integriert und die meisten von ihnen haben keine Unterstützung im udev-Subsystem, aber irgendwann sollte sich das ändern. In Verbindung mit einem Redundanzanbieter, z. B. auf einem MD, auch bekannt als Linux-Software-RAID, sollte es möglich sein, nicht nur Bitfäule zu erkennen, sondern auch E/A-Anforderungen an gesunde Daten umzuleiten, da dm-integrity anzeigen würde, dass es eine gibt Problem und MD sollte sich darum kümmern.
dm-Integrität
Siehe:Documentation/device-mapper/dm-integrity.txt
dm-integrity würde normalerweise im Journaling-Modus verwendet werden. Bei Swap könnte man auf das Journaling verzichten. Dies könnte den Performance-Overhead erheblich senken. Ich bin mir nicht sicher, ob Sie die Swap-over-Integrity-Partition bei jedem Start neu formatieren müssten, um Fehler nach einem unsauberen Herunterfahren zu vermeiden.
In der ersten Ankündigung von dm-integrity , gibt der Autor stattdessen eine Präferenz für „Datenintegritätsschutz auf höherer Ebene“ an. Im Fall von Swap würde dies die Möglichkeit eröffnen, die Prüfsummen im RAM zu speichern. Diese Option würde jedoch sowohl nicht triviale Modifikationen des aktuellen Auslagerungscodes erfordern als auch die Speichernutzung erhöhen. (Der aktuelle Code-Tracks-Swap nutzt Extents effizient, nicht einzelne Seiten/Sektoren).
DIF/DIX?
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önnten sich an Ihren Anbieter wenden. Ich weiß nicht, wie du erkennen kannst, ob sie darüber lügen.
DIX ist erforderlich, um Daten in Flight zwischen dem Betriebssystem (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:Präsentation mit einigen Zahlen zur Differenz der Fehlerquoten).
Gerade weil die Prüfsumme im Guard-Feld standardisiert ist, ist es technisch möglich, DIX-Befehle ohne Angabe von irgendeinem zu implementieren Schutz für ruhende Daten. Lassen Sie einfach den HBA (oder das Speichergerät) die Prüfsumme zur Lesezeit neu generieren. Diese Perspektive 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
- Erkennung erfolgt zur READ-Zeit
- ... das kann Monate später sein, der ursprüngliche Puffer geht verloren
- Jede redundante Kopie kann auch schlecht 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 Probleme herausfinden, bevor der ursprüngliche Puffer aus dem Speicher gelöscht wird
-- lpc08-data-integrity.pdf von oss.oracle.com
Einer ihrer frühen Beiträge zu DIX erwähnt die Möglichkeit, DIX zwischen Betriebssystem und HBA zu verwenden, selbst wenn das Laufwerk DIF nicht unterstützt.
Eine vollständige Verlogenheit ist in "Unternehmenskontexten", in denen DIX derzeit verwendet wird, relativ unwahrscheinlich. die Leute würden es merken. Außerdem basierte DIF auf vorhandener Hardware, die mit 520-Byte-Sektoren formatiert werden konnte. Das Protokoll zur Verwendung von DIF erfordert angeblich, dass Sie zuerst das Laufwerk neu formatieren, siehe z. die sg_format Befehl.
Wahrscheinlicher ist eine Implementierung, die nicht dem wahren Ende-zu-Ende-Prinzip folgt. Als Beispiel wird ein Anbieter genannt, der eine schwächere Prüfsummenoption für DIX unterstützt, um CPU-Zyklen zu sparen, die dann weiter unten im Stack 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 sie im Anwendungs-Tag-Raum speichern. Im aktuellen Linux (v4.20) wird dies jedoch nicht unterstützt. Der Kommentar aus dem Jahr 2014 legt nahe, dass dies daran liegen könnte, dass „sehr wenige Speichergeräte tatsächlich die Verwendung des Anwendungs-Tag-Speicherplatzes zulassen“. (Ich bin mir nicht sicher, ob sich dies auf das Speichergerät selbst, den HBA oder beides bezieht).
Welche Arten von DIX-Geräten sind verfügbar, die mit Linux funktionieren?
Die Trennung der Daten- und Integritäts-Metadatenpuffer sowie die Wahl der Prüfsummen wird als Data IntegrityExtensions [DIX] bezeichnet. Da diese Erweiterungen außerhalb des Geltungsbereichs der Protokollgremien (T10, T13) liegen, versuchen Oracle und seine Partner, sie innerhalb der Storage Networking Industry Association zu standardisieren.
-- v4.20/Documentation/block/data-integrity.txt
Wikipedia sagt mir, dass DIF in NVMe 1.2.1 standardisiert ist. Für SCSI-HBAs scheint es etwas schwierig zu sein, dies festzulegen, wenn wir keinen Standard haben, auf den wir verweisen können. Im Moment ist es vielleicht am genauesten, von "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 Speicher-Array-Konfiguration. DIF/DIX wird auf anderen Konfigurationen nicht unterstützt, es wird nicht für die Verwendung auf dem Startgerät unterstützt und es wird nicht auf virtualisierten Gästen unterstützt.
Derzeit sind die folgenden Anbieter dafür bekannt, diese Unterstützung bereitzustellen...
-- RHEL 7.5 Versionshinweise, Kapitel 16. Speicher
Die gesamte Hardware, die in den Versionshinweisen zu RHEL 7.5 erwähnt wird, ist Fibre Channel.
Ich kenne diesen Markt nicht. Es hört sich so an, als ob DIX in Zukunft auf Servern häufiger verfügbar sein könnte. Ich kenne keinen Grund, warum es für Consumer-SATA-Festplatten verfügbar werden sollte - soweit ich weiß, gibt es nicht einmal einen De-facto-Standard für das Befehlsformat. Ich bin gespannt, ob es auf NVMe breiter verfügbar wird.