Habe das mit Windoof Raid mal getestet und wie könnte es aderst zu erwarten sein auch da ein Verify
ich hätte gehoft das der sich evl merkt wo er gerade am schreiben war und nur dort das macht, ein schlauer programierer könte sowas sicher einbauen.
Danke für's Testen. Wissen tat ich es ja auch nicht.
Das mit dem
"merken" ist gar nicht so einfach. Irgendwo merkt er sich ja schon, ob er die Daten auf alle Platten oder nur einen Teil geschrieben hat als der Reset oder das Ausschalten (funktioniert's da eigentlich auch?) Ereignis eintrat. Anscheinend fehlen dort ein Bits um auch die Festplattenpositionen festzuklopfen und diese anschließend auszuwerten.
Ich weiß ohnehin nicht wo er sich das
merkt. Kann mir kaum vorstellen, dass er dafür die Sektoren nimmt in denen er auch die RAID Metainformationen ablegt. Schreib'/Lesekopf müsste so ständig beim Handshaken hin und her fahren. Die Performance würde beim Sequentiellen Schreiben drastisch sinken.
NVRam aus Flash ist zum einen relativ langsam u. zum anderen kann man's nicht beliebig oft überschreiben. Genau das wäre hier der Fall. Es ist aber auch wirklich zu langsam: Im normalen Nicht-AHCI Modus ist die maximale Übertragungsblockgröße per Busmaster DMA vom Hauptspeicher zum Controller 64kb. Der ICHxR hat nur ein paar Register, aber kein Ram; kann nix bündeln und schiebt die 64kb Blöcke rüber zur SATA Platte. Bei Übertragungsraten >100MB/s und sogar >200MB/s im RAID Fall sind das alle 0,3ms ein Übertragungsblock den Du mittels NVRam handshaken müsstest. Also alle 0,15ms ein Schreibzyklus. Nur aufwändig zu schaffen und der ICHxR ist ja eher Beigabe als vollwertiger RAID Controller.
Möglicherweise gibt's im BIOS ohnehin ein Bit, dass mitteilt, ob der Computer über ACPI ordnungsgemäß abgeschaltet wurde oder außerordentlich. Und bei allen außerordentlichen wäre ein Verify notwendig. Die Statusinformationen zwischen Resets könnte er in (un-)dokumentierten ICHxR Registern ablegen.
imho hat so ein verifi aber nur bedingt sinn, denn in den meisten fällen ist das file e'h hin nach nem Reset also was solls ob es Parität hat oder nicht?
Ohne Verify geht Dir die Konsistenz über Board:
1. Nimm an alle Daten sind geschrieben bis auf Parity (das Beispiel geht auch anders rum, wenn Du zuerst Parity schreibst)
2. Reset
3. Filesystem stellt letzten Zustand her. Ist egal ob Journaling Filesystem (NTFS, ext3) oder chkdsk per Hand angestoßen (FAT32, ext2). Journaling geht natürlich schneller
4. jetzt schreibst einen Monat fleißig weiter Daten
5. eine Platte fällt aus, aber nicht die, die in 1. die Platte mit dem Parity war
6. Jetzt werden die
falschen Daten restauriert. Nämlich diejenigen aus dem
falschen/alten Parity.
7. das zerlegt Dir im Worstcase (wenn's das MasterFileTable war) das gesamt Filesystem. Zumindest aber Daten.
Der Fehler kam daher, dass das RAID die ganze Zeit "falsche Daten" mit rumgeschleppt hat, die aber nicht auffielen, da es nur die Redundant Informationen waren, die bei fehlerfreien, normalen Zugriffen überhaupt nicht benötigt werden.
Das Verify
stellt Konsistenz her. Dabei ist sogar egal wie es in obigen Fall verfährt: Es ist egal ob es aus den "alten" Parity Daten die Daten rekonstruiert. Oder ob es das Parity neu berechnet. Der nachfolgende Filesystem Check (egal ob Journaling oder nicht) geht auf den letzten gültigen Checkout zurück. Es bleibt alles konsistent.
Ohne Verify läufst mit einer tickenden Bombe rum. Kann natürlich auch gut gehen, wenn Du zufällig die Sektoren mit den falschen Daten im Laufe der Zeit mal überschreibst und ein Rebuilt erst danach fällig ist.
Gibt's ne Möglichkeit Beim Intel oder Mein Windows das Verifi abzubrechen.
Gute Frage, aber es wäre gefährlich. s.o.
ZFS vermischt RAID + Filesystem. Möglicherweise sind aus dieser Symbiose ein paar Optimierungen möglich (eben bzgl. Verify), die im Moment nicht möglich sind, da das RAID nix über das Filesystem weiß. Würde ZFS aber eher erst reifen lassen.
