Die vermischen hier 3 Sachen die miteinander nicht viel zu tun haben:
Torn Writes aka. Torn Pages aka. ...
Das kann passieren wenn ein Schreibvorgang unterbrochen wurde. Statt AAAA oder BBBB kann also BAAA oder ABAB oder ABBB oder sonstwas auf der Disk stehen. Im schlimmsten Fall, nämlich wenn die Platte so doof ist dass sie nichtmal einzelne Sektoren "atomic" schreiben kann, kann auch ABXB oder sowas drinnen stehen.
Das ansich stellt IMHO noch kein Problem dar, wenn auch die Sache sehr lästig wird wenn man mit "zerrissenen Sektoren" rechnen muss - weil man viel öfter flushen muss, und sich an mehr Stellen auf Checksummen verlassen muss.
Das ist aber ein Problem welches mit RAID überhaupt nix zu tun hat, die Verwendung eines RAID Systems macht das weder besser noch schlechter. Ausnahme wäre hier ein RAID mit "commit to cache", da man bei so einem System zumindest nichtmehr mit "zerrissenen Sektoren" rechnen muss. Darauf dass ein Schreibbefehl der mehr als einen Sektor schreibt "atomic" ausgeführt wird kann man sich aber auch mit "commit to cache" nicht verlassen.
Von einem RAID System zu fordern dieses Problem zu lösen ist IMHO auch komplett unvernünftig, da es kaum möglich ist -- zumindest nicht solange das RAID System transparent arbeiten soll, denn dafür wäre eine Änderung des Storage-Device-Interface notwendig.
Das "redundant copies in different states" Problem.
Das ist das wovon ich die ganze Zeit rede
Und das ist ein Problem welches mit einem RAID System existiert, ohne RAID allerdings nicht. Daher muss es IMHO auch das RAID System transparent lösen, da es nicht sein kann, dass ein System welches für das OS bzw. die Programme transparent arbeiten sollte, Garantien wegnimmt die eine einfache Platte noch bietet.
----
In dem zitierten Abschnitt werden nun beide Probleme vermischt, was ich für unglücklich halte, da sie IMHO miteinander nix zu tun haben. Garnichts.
Hier steht nochmals das, was ich zu sagen versuchte. Leider ohne Quellen. Aber hier wird nochmals der Zusammenhang zwischen RAID und Filesystem angesprochen. Insbesondere löst ein Journaling-FS die Inkosistenzprobleme, da es den Schreibvorgang wiederholt, falls die Operation von Controller nicht als abgeschlossen bestätigt wurde.
Ein FS welches (wie NTFS) nur Änderungen an Metadaten, nicht aber am File-Inhalt logt, löst dieses Problem aber nur für eben diese Metadaten. (Wenn überhaupt, da ein System welches "atomic transactions" ermöglichen soll, aber ohne Rücksicht auf Problem #2 programmiert wurde, u.U. auch davon ausgeht dass einmal gelesene Daten "stabil" sind, und dann genauso versagt.)
Solange man aber Problem #2 nicht irgendwie auch für "Userdaten" behandelt kann es immernoch passieren dass ich nach dem Stromausfall "Foo.txt" im Notepad aufmache, den Inhalt angucke und alles passt -- und ein paar Sekunden später "Foo.txt" nochmal aufmache, und auf einmal was ganz anderes drinnen steht. Und genau das darf eben nicht sein, da viele Programme damit nicht klarkommen werden.
