HW-RAID mit ReFS oder Storage Spaces mit ReFS?

[McStarfighter]

Hallo auch,

ich plage mich seit geraumer Zeit mit den unterschiedlichsten Aussagen im Internet rum und bin mittlerweile vollkommen verunsichert. Daher erhoffe ich von euch sachkundige und differenzierte Hilfe.

Meine Wenigkeit hat einen 42HE-Server mit einem PC-Teil und 12x MSA60 Enclosures von HP. Die Enclosures hängen via Daisy Chaining an einer Adaptec 78166 RAID Controller-Karte. Als Festplatten kommen die 8TB Video Surveillance HDDs von Seagate zum Einsatz. Aktuell habe ich noch Desktop-Komponenten im PC-Teil, die weichen im Sommer aber einem Supermicro-Board mit Xeon-CPU und ECC-RAM. Geht nicht früher!
Der Einsatzzweck: Ich sammle mit großer Leidenschaft Filme und Serien auf Blu Rays (oder auf DVD, wenn nicht anders zu kriegen!) sowie Audio-CDs und die werden von mir digitalisiert und auf dem "Emby Tower" abgelegt. Dort wartet dann der Emby Server darauf, alle Infos zu ziehen und hübsche passende Grafiken zu holen.
Der PC ist auch gleichzeitig die "Workstation", damit die Scheiben überhaupt auf den Server kommen und von mir weiterverarbeitet werden (per RDP).

Den Emby Tower habe ich darauf ausgelegt, mich bis zum Ende meines Lebens zu begleiten (wobei natürlich Teile verschleißen und dann ersetzt werden!) und suche noch immer nach dem richtigen Konzept zur Storage-Struktur.
Als OS dient mir aus verschiedenen Gründen Windows Server 2016 (bestimmte essentielle Programme gibt es nur für Windows!).
Den Storage selbst (aktuell 12x 8TB) habe ich als RAID5 via Adaptec Controller realisiert, als Dateisystem dann ReFS mit aktivierten Integrity Streams. Der RAID wird vom Controller regelmäßig auf Konsistenz hin überprüft.

Leider macht mir das Internet arge Kopfschmerzen, da ich allzu oft lese, dass HW-RAID nix tauge, es nicht gegen Bit Rot helfen kann und daher der Datenverlust vorprogrammiert sei. Zudem seien die neuen CoW-Dateisysteme auf HW-RAIDs ebenfalls ungeeignet, ReFS könne sich darauf nicht mal selbst heilen und würde kaputte Dateien dann auch nicht löschen können.

Mein bisheriger Plan war eigentlich: Ich mache ein MA60 voll und erstelle ein RAID5. Dann kaufe ich mir weitere 12 Platten zusammen und migriere die mit dem bisherigen RAID5 zu einem RAID6. Wenn ich weiter ausbaue, dann erstelle ich ein neues RAID5 mit 12 Platten, wiederum erweitert auf ein RAID6 mit 24 Platten. Diese Volumes will ich in Windows als spanned Disk verbinden und so stets ein einziges Volume in Windows haben (will ich unbedingt so haben!). Dateisystem wie bisher ReFS.
Jetzt bin ich verunsichert und überlege, ob ich mit Storage Spaces inkl. ReFS besser fahren würde. Wobei ich auch da die 12er Schritte gehen will und mir auch da die Verbindung via spanned Disk wichtig ist.

Linux, BSD, ZFS und btrfs sind und bleiben für mich keine Optionen. Also bitte keine Missionierungen!

Und nun frage ich mich: Ist HW-RAID wirklich langfristig so schlecht für mich, ist Storage Spaces besser für mein Projekt, etc.? Eben all die Fragen, die sich aus der Verunsicherung so ergeben.

Ich danke schon mal für fachkundiges Feedback!

 

[fdsonne]

Jetzt bin ich verunsichert und überlege, ob ich mit Storage Spaces inkl. ReFS besser fahren würde. Wobei ich auch da die 12er Schritte gehen will und mir auch da die Verbindung via spanned Disk wichtig ist.

Linux, BSD, ZFS und btrfs sind und bleiben für mich keine Optionen. Also bitte keine Missionierungen!

Und nun frage ich mich: Ist HW-RAID wirklich langfristig so schlecht für mich, ist Storage Spaces besser für mein Projekt, etc.? Eben all die Fragen, die sich aus der Verunsicherung so ergeben.

Ohne genau auf die Details einzugehen. Das Problem scheint mir eher zu sein, dass du mit einen Hardware Raid unter dem Windows Filesystem jegliche Möglichkeiten verlierst, bei Problemen mit den Daten diese entsprechend zu korrigieren. Dieses System lebt effektiv ja davon, dass es einfach je nach "Raidlevel" Zugriff auf die Disks hat. Kurzum, wenn da Probleme mit dem Volume sind, hat das OS keinen Zugriff auf die Parity Disks um zu korrigieren. -> Wenn du einfach nur ein Volume native vom Hardware Raid deines Shelfs/Controllers 1:1 an das Windows OS klemmst... Es entscheidet am Ende also der Controller, was passiert wenn da was schief läuft mit den Bits. In Zweifel zersägst du dir das Teil und ReFS kann genau gar nix tun... Auch die Storage Spaces nicht, denn es ist ja nur EIN Volume mit einem ReFS Filesystem drauf.

Aus meiner Sicht wäre die sinnigere Methode entweder voll und ganz auf Storage Spaces zu gehen -> das heist die Disks einzeln bzw. das ganze Shelf mit Disks einzeln in Summe an die Windows Kiste klemmen und mit Storage Spaces zu einem double Parity Volume zusammen zu schrauben. Oder eben mit einer Zwischeninstanz zu arbeiten. Sprich einer Art Storage Server, der dir genau den (wichtigen) Part übernimmt, einerseits die Raidlevel zu verwalten und mit dem richtigen Filesystem kommt -> und obenraus das/ein Volume einfach an deine Windows Kiste durchreicht.

Es geht natürlich auch voll in "Hardware". Kommt dann aber stark auf die Appliance an. Mit ner MSA und nem schöden Adaptec Controller bleibst du aber weit hinter den Möglichkeiten aktueller Umsetzungen (in Software).
Technisch gesehen könntest du auch auf ReFS im Windows verzichten, wenn du zwischen deinem Windows am Ende der Kette und der Hardware eine Storage Appliance welcher Art auch immer zwischen klemmst, denn der Effekt geht ja eher gegen Null.



Am Ende ist es aber einfach nur eine Frage, was du für besser hälst, du wirst Leute für so ziemlich jede Umsetzung finden. Und alle erzählen sie dir, das ihre Lösung die Beste ist. Nur musst du am Ende damit klar kommen Um so schwieriger sind halt Empfehlungen.

 

[McStarfighter]

Zuerst einmal vielen Dank für die schnelle Antwort!

Die Frage, die sich mir seit jeher stellt, ist: Ist für die langfristige Datenkonsistenz ein HW-RAID oder das Windows Storage Spaces besser? Und dann noch die Anschlußfrage, ob SS denn was taugt!
Mir geht es einzig und alleine darum, die abgelegten Daten auch noch nach 25 Jahren im gleichen Zustand zu haben wie heute. Und dass ich eben nur ein Volume zu verwalten habe (daher auch die Sache mit den spanned Disks), im Grunde also ein überdimensionales NAS!
Ich brauche kein Dedup, keine Kompression (macht mit HD-Filmen auch keinen Sinn!) und so, nur die Datenerhaltung.

Von daher wäre ich für eine klare Empfehlung dankbar: HW-RAID oder Storage Spaces? Und ist Storage Spaces an sich wirklich empfehlbar?

 

[besterino]

Keine Hardware wird die nächsten 25 Jahre überdauern. Da ist immer wieder ein Tausch angesagt, weshalb ich tendenziell eher auf Software setzen würde - damit ist ein Umzug leichter, solange Du eben die Datenträger mitnehmen kannst. Klar, auch bei Software weiss kein Mensch was in 25 Jahren ist, aber überlege nur einmal, wie lange es die software-dateisysteme wie NTFS und ext2-4 schon gibt (und die werden immer noch unterstützt) und dann vergleiche das mal mit der Abwärtskompatibilität eines beliebigen Hardware-Raidcontrollers....

 

[MicroCane]

Zum Thema Bitrot: Bei Geschäftskritischen Daten sind Systeme wie ZFS, ReFS oder WAFL (NetApp-Dateisystem) natürlich sinnvoll.
In deinem Fall kannst du meiner Meinung nach darauf verzichten. Wenn man irgendwann 1 bit kippt hast du höchstwahrscheinlich (Aufgrund des Verhältnisses Bilddaten-Metadaten) in einem deiner Filme in einem Bild (von 25 pro Sekunde) einen falsch gefärbten Pixel. Das dürfte wohl unkritisch sein.

 

[McStarfighter]

Ich danke euch allen sehr!

Besonders der letzte Post hat mich dazu gebracht, dann doch bei meinem jetzigen Weg zu bleiben. Sicher, Hardware kann (und wird) irgendwann den Geist aufgeben. Aber dann ersetzt man sie eben. Ich bin ja schon länger mit Adaptec-Controllern zu Gange und die waren bisher immer untereinander kompatibel, auch generationsübergreifend. Festplatten kann man auch leicht austauschen, ebenso Mainboards oder RAM oder ne CPU!
Letzten Endes kann keiner in die Zukunft sehen und wer weiß, eventuell wird NTFS ja mal komplett von ReFS abgelöst. Oder Microsoft findet auf einmal sein Storage Spaces doof, oder was auch immer.

Ach ja: Tolle Art des Feedbacks! So habe ich meine innere Ruhe und Sicherheit wieder gefunden!

 

[the_pi_man]

Ich betreibe etwas ähnliches: Stichwort Serienjunkie! Ich habe mich für Software und ZFS entschieden. seit ca. 3 Jahren läuft es mit 5 x 3 TB Platten als Raid5 und wird in den nächsten Monaten durch 10 x 4 oder 6TB abgelöst. Das dann aber als Raid6. Erweitern lässt sich das dann immer in 10-Platten-Schritten. Noch ist es in normalen Gehäusen, aber wenn die übernächste Erweiterung ansteht wird es wohl in 19 Zoll umziehen (müssen).

 

[VirtuGuy]

Leider macht mir das Internet arge Kopfschmerzen, da ich allzu oft lese, dass HW-RAID nix tauge, es nicht gegen Bit Rot helfen kann und daher der Datenverlust vorprogrammiert sei. Zudem seien die neuen CoW-Dateisysteme auf HW-RAIDs ebenfalls ungeeignet, ReFS könne sich darauf nicht mal selbst heilen und würde kaputte Dateien dann auch nicht löschen können.

Es spricht nichts dagegen auf dem Raidset mit ReFS zu arbeiten. Sofern man keine Features von NTFS benötigt, würde ich bei derartigen Kapazitäten nur noch auf ReFS setzen.

Diese Volumes will ich in Windows als spanned Disk verbinden und so stets ein einziges Volume in Windows haben (will ich unbedingt so haben!).

Spanned Disk = Raid0 => in dem Fall wäre die Frage nach dem Filesystem keinesfalls deine größte Sorge


Sofern du die Daten wirklich erhalten willst, solltest du eher auf statische Backups setzen. Vergleichsweise günstig wäre ein LTO Laufwerk, da kannst du mit unter 10 Euro pro TB rechnen.

 

[McStarfighter]

Das spanned Disk besteht aus den hardwarebasierenden RAIID6, da ist meine Sorge jetzt nicht soooo groß!

Und letzten Endes habe ich bereits ein Backup: All die Blu Rays, DVDs und Audio CDs bei mir hier zu Hause. LTO wäre bei den schon jetzt erreichten Speichermengen nicht so ganz mein Ding, da ist eine Blu Ray schneller ausgepackt und nochmals eingelesen.

ich darf mich einfach nicht immer so verunsichern lassen ...

 

[Holt]

RAIDs ersetzen keine Backups!

Bit-Rot ist ein Thema welches vor allem von RAM Fehlern kommt, meist im RAM des Rechners und zuweilen im Cache RAM der Platte selbst, denn gerade einfache Consumer HDDs haben oft keinen Schutz der internen Datenpfade und nicht einmal eine Fehlererkennung, wie man auch am Fehlen des S.M.A.R.T. Attributes 0xB8 Ende-zu-Ende Fehler erkennen kann. Dann gibt es noch ein Risiko bei dem RAM/internen Puffer des Host Controller, aber professionelle SAS RAID Controller haben ECC RAM und von FW Bugs, vor denen man weder bei den HDDs noch den Host Controller zu 100% sicher sein kann, die aber trotzdem sehr selten sind. Bei den HDDs gilt aber, dass diese bei Lesefehlern keine falschen Daten liefern, wie es oft geglaubt wird, sondern einen Lesefehler (von der Nutzung besonderer Befehle abgesehen) und dann wird das RAID die Daten aufgrund der Daten der anderen Platten die auch die Parity beinhalten einfach rekonstruiert und der betroffene Sektor überschrieben.

Es ist also nicht so, als wäre man nur mit CoW Filesystemen in der Lage länger Storages mit einige Dutzend TB zu betreiben und diese haben auch Nachteile. So kann man bei ZFS eben nicht einfach so weitere Platte in das RAID integrieren wie es bei allen normalen RAID Lösungen geht. Keine Ahnung wie das da bei Storage Spaces und ReFS aussieht, aber wenn Du einen HW RAID Controller hast, kannst Du ja im Prinzip wählen ob Du das RAID mit dem HW Controller oder über SW machst.

 

[gea]

RAIDs ersetzen keine Backups!

Bit-Rot ist ein Thema welches vor allem von RAM Fehlern kommt, meist im RAM des Rechners und zuweilen im Cache RAM der Platte selbst,

Da kann man auch anderer Meinung sein.
Bitrot oder treffend neudeutsch "Datenrost" sind Veränderungen die mit einer statistischen Häufigkeit auf dem Datenträger selbst auftreten also nicht nur Probleme während des Schreibens sondern alle Veränderungen die auch nachträglich Daten korrumpieren. Ich halte diesen Veränderungen rein durch Lagern sogar als gravierender als Probleme beim Schreiben. Das ist ja auch mit "Datenrost" gemeint. Es ist damit vor allem ein Problem der Langzeitspeicherung und vor allem ein Problem bei sehr großen Datenmengen.

Der einzige Schutz oder besser die einzige Möglichkeit bitrot zu erkennen und zu reparieren sind Prüfsummen auf den Daten selber. Bei ReFS muss man das extra aktivieren. Das setzt sonst Prüfsummen nur auf Matadaten.

Was bedeutet Silent-Data-Corruption / Bit-Rot? - speicherguide.de
Die vernachlässigte Gefahr: Silent Data Corruption | it-administrator.de

 

[Equinox]

Bei den HDDs gilt aber, dass diese bei Lesefehlern keine falschen Daten liefern, wie es oft geglaubt wird, sondern einen Lesefehler (von der Nutzung besonderer Befehle abgesehen) und dann wird das RAID die Daten aufgrund der Daten der anderen Platten die auch die Parity beinhalten einfach rekonstruiert und der betroffene Sektor überschrieben.

Nur als Hinweis, das ist in diesem Zusammenhang so nicht ganz richtig. Bit-Rot muss nicht zwangläufig einen Lesefehler verursachen, da weder die Daten an sich noch das Laufwerk physisch beschädigt sind. Strenggenommen hängt das von der Anzahl der Flips und der Länge (bzw. Art) des ECC ab. Ein Lesefehler kann nur ausgegeben werden wenn er als solcher erkannt wird. Anders sieht es natürlich aus wenn dir bit-rot den ECC selbst verändert oder in sensibleren Bereichen der Platte auftritt. Dann wären die Daten an sich in Ordnung, können aber u.U. nicht mehr gelesen werden.

Bit-rot auf Dateisystemebene festzustellen wäre bei normalen Platten nur möglich wenn - wie gea schon geschrieben hat - die Prüfsumme sämtlicher Dateien berechnet, vor dem Lesen abgeglichen und nach dem Schreiben aktualisiert wird. Selbst in dem Fall wäre es aber theoretisch möglich, dass bit-rot dir die Prüfsummen zerschießt, dann wären (ähnlich wie oben) die Dateien an sich in Ordnung, aber eine Validierung dessen nicht möglich.

Ähnliches kann dir u.U. auch in bestimmten RAID-Konfigurationen passieren (es gab da vor einiger Zeit mal ein Diskussion im flexraid-Forum) und abhängig von der Fallkonstellation die Parity zerschießen wenn nicht regelmäßig validiert wird.

Hängt letztendlich davon ab wie häufig bit-rot auftritt.

 

[martingo]

LTO wäre bei den schon jetzt erreichten Speichermengen nicht so ganz mein Ding, da ist eine Blu Ray schneller ausgepackt und nochmals eingelesen.

Das wage ich zu bezweifeln. Das tatsächliche Einlesen mal außen vor, so dauert doch allein das ständige disc wechseln "bei den schon jetzt erreichten Speichermedien" sicher Tage.

Nichtsdestotrotz wäre es mir auch zu kostspielig, ohne weiteres wieder beschaffbare Medien auf Band zu sichern. Die meiste Arbeit steckt meist in der Datenbank und die wird sich wohl maximal im zwei- bis dreistelligen GB Bereich bewegen.

 

[CommanderBond]

Das spanned Disk besteht aus den hardwarebasierenden RAIID6, da ist meine Sorge jetzt nicht soooo groß!

Und letzten Endes habe ich bereits ein Backup: All die Blu Rays, DVDs und Audio CDs bei mir hier zu Hause. LTO wäre bei den schon jetzt erreichten Speichermengen nicht so ganz mein Ding, da ist eine Blu Ray schneller ausgepackt und nochmals eingelesen.

ich darf mich einfach nicht immer so verunsichern lassen ...

Ich persönlich halte von diesen klassischen Raid Geschichten nichts. Man darf auch nicht vergessen wo das ursprünglich herkam, nämlich daher dass man ein Dateisystem/Partition über mehrere Disk hinweg betreiben wollte. Weder die klassiche Parition noch klassische Dateisysteme können das von sich aus allein.
Moderner sind da Cow Dateisysteme wie ReFS, btrfs und ZFS welche alle kein klassisches Raid mehr benötigen und eigentlich nur Vorteile dadurch haben.
Auch MS geht ja durch die Storage Spaces diesen Weg.
Ich habe ZFS gewählt aus folgenden Grund: ReFS und Storage Spaces vielen raus, weil das ist noch irgendwo in der "Erprobungsphase" von MS. Ferner habe ich nicht Lust auf MS zum einen mal weil es closed source ist und niemand so wirklich weiß was es letztendlich tut im heimlichen, aber ich habe auch keine Lust dass ich irgendwann dastehe weil MS mal die Strategie ändern. Als Student kommt man noch einfach an eine MS Server Lizenz ran. Doch was ist irgendwann später mal? Will ich das OS dann ne halbe Ewigkeit weiternutzen oder muss ich mir dann irgendwann ein neues MS Server kaufen für eine unbestimmte Summe X ?
Der einzig wirklich Vorteil wäre daran der SMB Server, doch MS schiebt auch nicht irgendwelche Features nach sondern die wandern dann in den Nachfolger den man sich dann wieder kaufen kann. SMB3 mit Windows 10 nützt dir auch nix wenn du irgendnen nicht aktuellen Windows Server laufen hast.
Hab mir auch Storage Spaces mal angeguckt, Virtuelle Laufwerke erstellen auf einem SS, dann eine Partition auf dem virtuellen Laufwerk und dann obendrauf noch ein Dateisystem erstellen gefiel mir nicht. Da fande ich ZFS an sich einfach logischer aufgebaut. Storage Spaces sind auch längst nicht so flexibel wie man meinen könnte. Als ich es mal getestet hatte und testweise die virtuelle Festplatte mit Daten befüllt habe und danach wieder die Daten gelöscht, stand der Platz witzigerweise nicht wieder zur Verfügung sondern war weiterhin an die virtuelle Festplatte gebunden. So hatte ich dann 2mal 40GB virtuelle Festplatten die leer waren, dennoch waren diese 80GB nicht nutzbar um ne 3. virtuelle Festplatte zu erstellen.
Bleiben noch ZFS und btrfs. ZFS gibt es schon länger und dementsprechend ausgereift ist es. btrfs hat durchaus Potential, was draus wird muss man dann irgendwann mal sehen. Finde daher momentan dass der ZFS Ansatz für mich am besten passt. Hauptvorteil wie gesagt die "Architektur" dahinter und dass es nicht closed source ist wie Microsoft Server.

Wenn ich weiter ausbaue, dann erstelle ich ein neues RAID5 mit 12 Platten, wiederum erweitert auf ein RAID6 mit 24 Platten.

Beides mehr als Riskant in meinen Augen. Selbst bei 12 Platten würde ich auf jedenfall schon Raid6 machen. Raid5 bedeutet, beim Ausfall einer Platte müssen alle anderen zu 100% funktionieren. Auf einer weiteren noch nen defekter Sektor und schon hast du zumindest teilweise Daten die weg sind.

Geht es um Filme so gibt es da aber auch bessere Lösungen wie FlexRaid, UnRaid. Da kannst du zumindest mit weniger Redundanz arbeiten weil du dann keinen SuperGau hast wie bei Raid5/6 sondern nur einen teilweisen Verlust der Daten, da jede Platte unabhängig von den anderen ist.

 

[Holt]

Bitrot oder treffend neudeutsch "Datenrost" sind Veränderungen die mit einer statistischen Häufigkeit auf dem Datenträger selbst auftreten also nicht nur Probleme während des Schreibens

Wo habe ich behauptet es hätte nur mit dem Schreiben zu tun? Nein, also unterstelle es mir auch nicht. Ebenso ist unstrittig, dass HDDs nicht immer alle Daten jedes Sektors korrekt lesen können, es gibt dafür in den Datenblättern in Form der UBER auch eine Angabe bis zu wie viele Unkorrigierbare Bitfehler auftreten dürfen, ohne die Spezifikation zu verlassen, die Angaben ist in Sektoren pro gelesener Bit und üblich sind für 3.5" <= 1 Sektor pro 10^14 oder 10^15 gelesenes Bits, was so 12 bzw 120TB entspricht.

Es ist damit vor allem ein Problem der Langzeitspeicherung und vor allem ein Problem bei sehr großen Datenmengen.

HDDs sind nicht endlos lagerbar, dazu schreibt Seagate z.B. hier und auch in einigen anderen Product Manuals:

The recommended storage period:
• 1 year under controlled conditions of 34°C 90%RH or less
• 90 days in uncontrolled storage conditions
...
Storage
The maximum recommended storage period for the drive in a non-operational environment is 90 days. Drives should be
stored in the original unopened Seagate shipping packaging whenever possible. Once the drive is removed from the
Seagate original packaging the recommended maximum period between drive operation cycles is 30 days. During any
storage period the drive non-operational temperature, humidity, wet bulb, atmospheric conditions, shock, vibration,
magnetic and electrical field specifications should be followed.

Wenn also die Lagerbedingungen nicht eingehalten werde, sind 90 Tage und zwar in der ungeöffneten Originalverpackung, sonst bestenfalls 1 Jahr. Nach dem Öffnen sollten HDD nicht länger als 30 Tage stromlos sein.

Bei der neuen Barracuda Pro 10TB mit Heliumfüllung schreibt Seagate:

2.10.2 Storage
Maximum storage periods are 180 days within original unopened Seagate shipping package or 60 days unpackaged within the
defined non-operating limits (refer to environmental section in this manual). Storage can be extended to 1 year packaged or
unpackaged under optimal environmental conditions (25°C, <40% relative humidity non-condensing, and non-corrosive
environment). During any storage period the drive non-operational temperature, humidity, wet bulb, atmospheric conditions,
shock, vibration, magnetic and electrical field specifications should be followed.

Also hier nur ein halbes Jahr in der ungeöffneten originalen Versandverpackung von Seagate und sonst 2 Monate, nur bei optimalen Bedingungen bis zu einem Jahr.

HGST schreibt für die Megascale:

Maximum storage period within shipping package is one year

Und sie sind nur auf eine Lebenserwartung von 5 Jahren ausgelegt, halte natürlich meist etwas länger, aber eben nicht ewig.

Component Design Life: 5 years

Für Langzeitdatenspeicherung sind HDDs weniger gut geeignet, aber die Langzeitarchivierung digitaler Daten ist sowieso ein besonderes Problem!

Der einzige Schutz oder besser die einzige Möglichkeit bitrot zu erkennen und zu reparieren sind Prüfsummen auf den Daten selber.

Das mit der einzigen Möglichkeit ist Quatsch mit Soße, denn jedes normale RAID hat auch Parity und kann damit bei Lesefehlern die Daten der Platte rekonstruieren die den Lesefehler gemeldet hat. Deine Aussage beruht auf der falschen Annahme, dass die HDDs in dem Fall auch falsche Daten liefern würden, nur ist dem eben nicht so. Das einzige was die Prüfsummen auf Dateieben können und was normale RAIDs nicht kompensieren können, ist der Fall von Fehlern auf den internen Datenpfaden oder FW Fehlern der Platten oder des Controllers sowieso ggf. Treiberbugs, was zwar zuweilen vorkommt, aber doch sehr selten ist. Wer davor Sorge hat, dem bleibt wirklich nur ein CoW Filesystem. Nur haben die eben auch Nachteile und Einschränkungen, da muss also jeder Abwägen was ihm wichtiger ist.

Aber hört auf den Quatsch zu propagieren den man immer wieder liest, wonach ein paar auf der Oberfläche kippen und dann bekommt man auch mit einem normale RAID (mit Redundanz) eine korrupte Datei. Dem ist nicht so, einer einer einzelnen HDD kann das passieren, wenn die SW die diesen Datei liest den Lesefehler ignoriert und so tut als wäre die Datei korrekt gelesen worden, aber sowas sollte nicht vorkommen, mies SW gibt es aber immer wieder. Bei einem RAID mit Redundanz wird das aber nicht passieren, denn auch wenn die HDD die gekippten Bits nicht mit der ECC korrigieren kann, dann meldet sie einen Fehler und schickt keine korrupten Daten, außer bei absichtlicher Herbeiführung dieser Situation durch Verwendung besonderer Befehle oder Konfigurationen, z.B. bei den ATA Streamingbefehlen für Echtzeitvideoaufzeichnung (die haben jeweils einen eigenen Timeout und es ist besser korrupte Daten als fehlende Frames zu bekommen wenn man sich ein Video ansieht).

Wenn der Lesefehler statt den Daten kommt, dann wird das RAID die Daten aus denen der anderen Platten rekonstruieren (und auf der betroffene Platte überschreiben) und dem Host die korrekten Daten liefern oder eben eben Fehler, sollte die Rekonstruktion fehlgeschlagen sein.

Ein Lesefehler kann nur ausgegeben werden wenn er als solcher erkannt wird.

Und wie hoch ist die Rate der unerkannten Bitfehler? Also die Wahrscheinlichkeit, dass die Bitfehler nicht erkannt wird?

Nur mal als Hinweis, hier die Berechnung für die Wahrscheinlichkeit das einer CRC32 über 8k Daten ein Fehler entgeht:

When we multiply this by the length of the code (because thus far we
calculated for a specific position) we have 10^-45 * 6.5*10^4 =
6.5*10^-41 as an upper bound on the probability of undetected burst
error for a code of length 8K Bytes.

Hier auch ein Hinweis wie große die ECC eines Sektors ist:

Galt für 512 Byte pro Sektor und bei Advanced Format sieht es so aus:


Damit bekommst Du das dann sicher ganz einfach selbst raus!

Anders sieht es natürlich aus wenn dir bit-rot den ECC selbst verändert oder in sensibleren Bereichen der Platte auftritt.

Erkläre doch mal genauer wie sich Bitfehler auf die ECC anderes als die auf die Daten auswirken und welche sensiblen Bereiche Du meinst?

Bit-rot auf Dateisystemebene festzustellen wäre bei normalen Platten nur möglich wenn - wie gea schon geschrieben hat - die Prüfsumme sämtlicher Dateien berechnet, vor dem Lesen abgeglichen

Dann erkläre mal wie denn Bitfehler auf Dateieben auftreten können, wenn jeder einzelne Sektor fehlerfrei gelesen wird, mit Ausnahme der schon von mit genannten Fehlerquellen (Datenpfade + FW/Treiber Bugs)?

Selbst in dem Fall wäre es aber theoretisch möglich, dass bit-rot dir die Prüfsummen zerschießt, dann wären (ähnlich wie oben) die Dateien an sich in Ordnung, aber eine Validierung dessen nicht möglich.

Wie gut kennst Du Dich denn eigentlich mit den dabei verwendeten Algorithmen aus? Scheinbar nicht so gut, denn man kann mit dem richtigen Algorithmus durchaus erkennen ob der Fehler in den Daten oder nur in der Prüfsumme vorhanden ist, aber wusstest Du ja sicher schon vorher und wolltest mich nur testen, richtig?

 

[ludwinator]

Hallo Holt,

ich schätze den fachlichen Inhalt deiner Beiträge zwar sehr, aber in letzter Zeit runinierst du deine Reputation zunehmend mit diesen unterschwelligen Beleidigungen. Liegt das an den Uhrzeiten deiner Beiträge?
Merkst du das eigentlich selber noch?

cu

 

[Equinox]

Holt, solange du bei Meinungen die von deiner eigenen Abweichen mit Ignorelisteinträgen "drohst" sehe ich ehrlich gesagt keinen Grund dir irgendwas zu erklären. Die Ausfallwahrscheinlichkeit eines ECC bei einer Festplatte mit der eines CRC zu vergleichen zeugt jetzt nicht unbedingt von Sachverständnis. Solange du von anderen detailierte Erklärungen erwartest, bei dir selbst aber offensichtlich keine Probleme mit Verallgemeinerungen hast musst du dich nicht wundern wenn andere das Ankreiden.

 

[Holt]

ludwinator, der Typ ist bei mir auf Ignore, der macht einen auf ganz schlau, aber es kommt dann nichts außer Beleidigungen. Oder hat der die Wahrscheinlichkeit wie oft ein Bitfehler auf einem Sektor einer HDD unerkannt bleibt schon berechnet und dies mit der für einen unerkannten Übertragungsfehler (je FIS mit bis zu 8192 Byte Daten gibt es eine CRC32 um solche zu erkennen) kombiniert? Wohl kaum, oder? Und nach so einem Spruch sollte man dann von mir auch keine Freundlichkeiten mehr, sondern nur noch die Eintragung in meine Ignoreliste erwarten.

Alter Schwede, sieh bloß zu dass du Land gewinnst, Leute wie dich kann ich schon im RL nicht ausstehen.

*******, wieso sind HW-RAID Controller unflexibel? Die sind in aller Regel in der Lage die RAIDs auf mehr Platten zu erweitern und bieten auch sonst alle Funktionen die man von einem RAID so erwartet. Natürlich sind sie nicht billig, von alter Gebrauchtware abgesehen die dann ggf. auch noch mit Einschränkungen beim Treiber-Support oder der Größe der unterstützen HDDs daher kommt, aber das ist dann ja auch wirklich alte HW. Unter Linux würde ich auch keinen HW RAID Controller sondern allenfalls eine HBA einsetzen, die md SW RAIDs sind denen kein Stück unterlegen und die CPUs haben viel mehr Performance und Resourcen als deren Controller. Aber Windows SW RAIDs sind bisher nicht wirklich für hohe Performance bekannt und wer unbedingt Windows nutzen möchte, der kommt dann meist um einen HW-RAID Controller nicht herum. Microsoft hat eben zu lange beim Unterbau nicht viel getan, während bei Linux das ganze I/O Subsystem massiv überarbeitet und auch parallelisiert wurde, die Redmonder wenden die Zeit eben lieber für Klicki Bunti auf.

 

[Equinox]

ludwinator, der Typ ist bei mir auf Ignore, der macht einen auf ganz schlau, aber es kommt dann nichts außer Beleidigungen.

Nein, der Typ kam sich auf Grund deines Verhaltens einfach nur verarscht vor. Quote-Mining klappt übrigens deutlich schlechter wenn man automatisch auf die gesamte Unterhaltung verlinkt. Ansonsten bleibt mir an der Stelle nur zu sagen dass ich dir viel Glück beim ignorieren wünsche, dann ist es hoffentlich an jemand anderem dir den Unterschied zwischen Halon und Helium zu erklären.

 

[Holt]

Es ging darum das es vor Jahrzehnten schon HDDs mit Helium gab, einen Links dazu hast doch auch noch selbst gepostet:

In the 1960s, Control Data (one of the earliest pioneers in computer research and technology) manufactured a helium-filled rotating drum. Other companies made similar attempts to fill HDDs with helium. All of these products used external helium tanks to maintain and replenish the internal helium atmosphere. This proved to be an inefficient and prohibitively expensive configuration that produced only very small numbers of drives.
...
Work restarted on helium-filled HDDs by the 1980s. ... However, the only product introduction from this effort was Patty—a helium HDD for NTT in Japan—widely considered a failure by NTT due to very fast helium loss through permeation.

Genau wie ich geschrieben habe, von Helium und nicht Halon war bei mir die Rede und Helium gab in HDDs schon vor Jahrzehnten, mit keinem Wort habe ich behauptet, dass es damals ein Erfolg war.

Trotzdem macht der Troll hier den Aufriss und unterstellt mir Dinge die falsch sind um sie lächerlich zu machen, was eben das typische
Verhalten von Trollen ist:

Vorausgesetzt Holt hält sich diesmal an seine Ankündigung muss ich damit auch diesen ominösen Satz:

Definiere bis jetzt! Nachdem es das vor Jahrzehnten schon mal gab, was Ende 2013 die HGST He6 die erste die das wieder hatte.

abschließend so deuten, dass er tatsächlich Helium und Halon verwechselt hat. Zumindest an der Stelle hätte ich mir etwas Aufklärung gewünscht, da ich wie gesagt nur von erfolglosen Versuchen gelesen hatte.

Da wundert Ihr euch über den Ton?

 

[ludwinator]

Nun red dich mal nicht auf einen Einzelfall raus, ich schätze das in den letzten Wochen nahezu 100% aller Verfasser, die nicht deiner Meinung sind, mit solchen patzigen Reaktionen von dir rechnen durften.
Das Festplatten Forum ist zeitweise gar nicht lesbar vor lauter Flame Wars, an denen du direkt beteiligt bist.

cu

 

[jdl]

… Oder hat der die Wahrscheinlichkeit wie oft ein Bitfehler auf einem Sektor einer HDD unerkannt bleibt schon berechnet …

Dir ist hoffentlich bekannt, dass es immer wieder zu Serienfehler bei Festplatten kommt? Was machst Du wenn Festplatten (Enterprise Platte für den HW RAID Controller zertifiziert) urplötzlich ohne Vorwarnung aus dem RAID Verbund geworfen werden, und sich nicht mehr wieder in den RAID Verbund integrieren lassen, weil die Platten vom RAID Controller als defekt markiert wurden? Nach vielen Telefonaten ließen sich die Platten irgend wie wieder reinwürgen und der Plattenhersteller lieferte sehr schnell neue Tauschplatten. Will heißen all Deine tollen theoretischen Überlegungen können durch ganz banale Fehler total über den Haufen geworfen werden.

 

[Equinox]

Trotzdem macht der Troll hier den Aufriss und unterstellt mir Dinge die falsch sind um sie lächerlich zu machen, was eben das typische
Verhalten von Trollen ist: Da wundert Ihr euch über den Ton?

Holt, es ging um die kommerzielle Verfügbarkeit die du impliziert hast, das hab ich im anderen Thread relativ ausführlich dargelegt. Ich hab dich um eine einfache Klarstellung auch in Bezug auf dein (Beweis?)-Video, in dem die Halon-Platte gezeigt wurde gebeten, darauf hin hast du sofort zu gemacht. Ich hatte mich dabei auch direkt auf den Sachverhalt (den Fehlschlag von NTT) den du zitierst bezogen. Wen es tatsächlich interessiert der kann es direkt im Thread nachlesen, ansonsten würde ich vorschlagen dass wir die Diskussion darum auch wieder dorthin verlagern (es sei denn du willst immer noch so tun als würdest du mich ignorieren). Außerdem würde ich dich (erneut) bitten auf das Quote-Mining zu verzichten oder die Sachen die du zitierst zumindest im Kontext wiederzugeben:

Es gab bis jetzt keine kommerziell verfügbaren Festplatten mit Heliumfüllung - willst du mir da immer noch widersprechen?

Definiere bis jetzt! Nachdem es das vor Jahrzehnten schon mal gab, was Ende 2013 die HGST He6 die erste die das wieder hatte.

Es ist eine Sache mich als Troll zu verunglimpfen, aber dann tu es bitte nicht auf so eine plumpe Art.

 

[Holt]

jdl, wenn der Host Controller eine HDD die er einmal auf einem RAID geworfen hat, warum auch immer das war, nicht wieder akzeptiert, dann ist das ja eine Sache des Herstellers dieses Controllers. Mit Bitfehlern hat das aber erstmal nichts zu tun und wenn es zu viele Platten betrifft, dann dürfte es zum Totalverlust des RAID führen, was bei ZFS Pools auch zuweilen vorkommt. Bugs können immer mal vorkommen, in der FW von HDD, SAS/SATA Host Controllern oder auch in RAID/FS SW, aber auch das hat nicht nicht damit zu tun wie hoch die Rate der von der ECC hinter jedem Sektoren einer HDD nicht erkannten Bitfehler ist.

100%ig sicher ist nichts, am nächsten kommen noch Mainframes da ran, weshalb die bei Banken und Versicherungen immer noch unersätzlich sind, obwohl ihr Ende seit Jahrzehnten vorhergesagt wird.