btrfs Prüfsummen ohne ECC RAM blödsinn?

@Piktogramm Simples Volumen. Es gibt googlebare statistische Kenndaten, wieviele Bitfehler pro Datenvolumen erwartet werden können, auch bezogen aufs Medium.

Das heißt natürlich nicht, daß einer auftreten wird. Es heißt aber, daß die Wahrscheinlichkeit für den Bitfehler irgendwann höher ist als die für keinen. Wenn ich oft genug würfel, dann hab ich irgendwann garantiert jede Zahl gesehen und dazu braucht es nicht mal besonders viele Versuche.
 
Eine andere Frage nebenbei. Bei einem RAID 5 können beschädigte Teilstücke ja wieder errechnet werden, bei einem RAID 1 liegen die Daten komplett redundant vor.

Der Schutz vor Bitrot wird aber durch btrfs gewährleistet. Das RAID wird also lediglich benötigt um eine Quelle zu stellen um Daten wiederherzustellen oder bietet ein RAID 5 zusätzlichen Schutz?
 
nein, einfach redundant ist beides.
aber raid 5 hat weniger verschnitt. braucht halt prozessorleistung.
raid 1 ned, weil die daten einfach an beide platten gehen, löst man es auf, hat man zwei platten mit demselben datenbestand. kein mapping, beide disks haben vollständige daten.
kostet halt 50% dees rohspeichers. was halt prozentuell viel ist.

deswegen gibts raid 5 (jaja, ein paar andere auch, lass ich jetzt aber weg), das braucht mindestens drei platten, bei drei platten 33% verschnitt, bei 4 25%, bei 5 eben nur 20%... usw. aber je mehr platten, desto verwundbarer.

weil die redundanz nur einfach ist, darf auch nur eine ausfallen, bei zwei gleichzeitig ist das raid tot.
raid 5 macht man üblicherweise mit drei oder fünf platten
raid 6, dasselbe mit doppelter redundanz dann meist mit sechs oder zehn. da dürfen zwei gleichzeitig sterben.

was halt mapping hat(5,6), braucht halt zur berechnung der korrekturdaten leistung.
aber eben das macht hardware raidcontroller auch teuer, eigener prozessor, eigener speicher, eigenes betriebssystem. ein rechner im rechner

sowas wie zfs (freenas) macht das alles über den prozessor, der sollte halt ein bissl was können, und klar, es will ram sehen, und nutzt das auch.
 
  • Gefällt mir
Reaktionen: Christian1297
Raid und veränderliche Daten ist so ne Sache. Btrfs weiß nichts von bitrot. Raid auch nicht. Wenn du fünf volle Platten für ein halbes Jahr neben den PC legst, weiß genauso wenig jemand, ob, in welchem Umfang, oder wo. Um Probleme zu finden führt kein Weg am vollständigen Anschauen vorbei.

Raid kann bitrot nicht korrigieren, nur erkennen, ggfs melden und verwerfen. Platte A sagt so und Platte B (r1) bzw Parity (R5+) paßt nicht dazu - okay, Problem. Aber was das richtige Datum sein soll kann RAID nicht ermitteln, dazu fehlt dateibasierte Validierung. Ggfs kann auch der Anwender gefragt werden... aber ist mir nichts bekannt, daß das gemacht wird.

Und wie gesagt, damit RAID den bitrot melden kann, muß es diesen erstmal sehen. Bei RAID wäre das buchstäblich Zufall, da Daten nicht geprüft werden.
 
BTRFS sollte Bitrot eigentlich bemerken, sobald der betroffene Block gelesen wird. Und bei RAID 1 (oder höher) sollte es dann auch automatisch auf die Kopie zurück greifen.
Ob es wirklich so läuft, hab ich zwar nicht nachgeprüft. Aber ansonsten würden die Prüfsummen ja kaum Sinn machen.
 
RalphS schrieb:
Raid kann bitrot nicht korrigieren, nur erkennen, ggfs melden und verwerfen. Platte A sagt so und Platte B (r1) bzw Parity (R5+) paßt nicht dazu - okay, Problem. Aber was das richtige Datum sein soll kann RAID nicht ermitteln, dazu fehlt dateibasierte Validierung. Ggfs kann auch der Anwender gefragt werden... aber ist mir nichts bekannt, daß das gemacht wird.

RAID 5 verkraftet doch den Ausfall einer Festplatte. Wenn jetzt ein Teilstück der Datei durch bitrot unbrauchbar ist kann doch aus den restlichen Dateien die das fehlende Teilstück errechnet werden?

RalphS schrieb:
Und wie gesagt, damit RAID den bitrot melden kann, muß es diesen erstmal sehen. Bei RAID wäre das buchstäblich Zufall, da Daten nicht geprüft werden.

Deswegen doch das Scrubbing oder nicht?
 
Wo es Scrubbing gibt, ja. RAID kennt kein Scrubbing.

Und nein, RAID kann nicht automatisch "auf die andere Kopie" zugreifen. Welche soll das denn sein?
Note, btrfs/ZFS ungleich RAID.
RAID kann sagen, okay Platte 2 ist nicht mehr da, also muß ich aus Platte 1 und ggfs anderen rekonstruieren.

Bei bitrot hingegen sind alle Platten noch da.
Wenn es mehrfache Parität gibt, sagen wir mit RAID6, und ein Datum ist hinüber, dann kann man ggs noch sagen: okay Datum 1 ist okay, Parität 1 auch, nur Parität 2 behauptet was anderes, gut, dann wird wohl P2 falsch sein.

Aber bei sagen wir RAID1 haben wir zwei mehr oder weniger identische Platten. Prüfsummen gibt es bei RAID nicht, es kann nur erkannt werden: hey Datum1 und Datum2 sollten identisch sein, aber sind sie nicht. Was nun? Keine Ahnung. RAID1 (oder 5) kann nicht entscheiden, was von den beiden defekt ist oder nicht, dafür müßte es beide Daten prüfen können, aber da RAID keine Checksums hat, kann es das ganz einfach nicht.

Exakt deswegen gibt es ja bei ZFS und btrfs diese Prüfsummen. Wir wissen zwar immer noch nicht, was der Benutzer da geschrieben hat, aber wir können prüfen, ob das was JETZT da steht, immer noch das ist, was DANN dastand, indem wir eine neue Prüfsumme über das existierende Datum bilden und dann diese mit der existierenden Prüfsumme vergleichen.

Auch das ist natürlich bis zu einem gewissen Punkt fehleranfällig. Zumindest theoretisch können Datum und Prüfsumme huch-na-so-was kongruent verfallen sein, sprich das Datum paßt immer noch zur Prüfsumme, weil beide "passenden" bitrot hatten.
Das wird normalerweise aber nicht passieren, schon gar nicht mit sowas wie SHA256, was üblicherweise dafür verwendet wird.
 
  • Gefällt mir
Reaktionen: Christian1297
Zurück
Oben