Große Arrays als Raid5 laufen lassen?

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Habe ich auch seit über einem halben jahr ohne ein Problem am laufen
 
Bin ich der einzige, der ein 16TB R5 bedenklich findet?

Also die Kapazität ist doch unwichtig (vor ein paar Jahren hat man das selbe wohl über 250GB Festplatten (250GB, verdammt ist das viel!) auch gesagt), vielmehr zählt die Anzahl der HDDs. Es sind ja netto auch "nur" 14TB, und das ist ja nicht komplett ausgelastet. Zudem mache ich von den wichtigen Daten (ca. 1TB) immer ein Backup, und wenn eine HD kaputt geht kann ich die sofort auswechseln. Mal ganz davon abgesehen (meine persöhnliche Meinung) würde ich ein R6 oder vergleichbar erst ab 10 Festplatten aufwärts einsetzen. Ich sehe das immer so das nicht eine Festplatte kaputt gehen darf, sondern das zwei zeitgleich kaputt gehen müssen damit das Raid futsch ist, und das halte ich einfach für unwahrscheinlich bei weniger als 10 HDDs. Man muss auch mal daran denken das tausende Menschen Weltweit nur eine Festplatte im Rechner haben, und diese Rechner laufen zig Jahre^^

Ich kann mich irren, aber ich glaube das defekte Festplatten weniger oft die Ursache für ein defektes Raid sind als viele denken.
 
Zuletzt bearbeitet:
Das Problem dass du hast, sind URE. Es gibt im Netz einen schönen Artikel, "why R5 is dead in 2009" oder so. Da wird das beschrieben. Um es grob zusammenzufassen:

Deine Platten haben alle ~12TB einen nichtkorrigierbaren Lesefehler. aktuelle Controller fangen mit dem Rebuild des Arrays afaik schon an, wenn eine Platte so einen URE zeigt, und nicht wenn dir eine ganze Platte abraucht. Das Problem bei einem R5: bei einem Rebuild hast du keinerlei Schutz gegenüber erneuten Ausfällen. Und wenn du den Inhalt von 7 Platten neu auslesen musst (~14TB ), hast du mit einer rechnerischen Wahrscheinlichkeit von 100% wieder einen URE.
 
Hier ist der selbe artikel in deutsch: Warum 2009 RAID 5 nicht mehr sicher genug ist

der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute) und weil er zum einen davon ausgeht dass das ganze raid voll ist, und zum anderen müsste das nicht lesbare byte auch noch paritätsdaten enthalten. zudem würde das bedeuten das man mit steigender kapazität immer mehr paritätslaufwerke braucht.

ich hatte irgendwo mal ne seite gfunden wo die ausfallwahrscheinlichkeit wie hoch bei wieviel festplatten ist, finde sie aber leider grade nicht wieder.
 
Hier ist der selbe artikel in deutsch:

Warum 2009 RAID 5 nicht mehr sicher genug ist

der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute) und weil er zum einen davon ausgeht dass das ganze raid voll ist, und zum anderen müsste das nicht lesbare byte auch noch paritätsdaten enthalten. zudem würde das bedeuten das man mit steigender kapazität immer mehr paritätslaufwerke braucht.

ich hatte irgendwo mal ne seite gfunden wo die ausfallwahrscheinlichkeit wie hoch bei wieviel festplatten ist, finde sie aber leider grade nicht wieder.

Wie es mir scheint hast du den Artikel nicht verstanden.

Es geht nicht darum, dass 2TB Platten Alltag sind, sondern dass die Größe eines Arrays die Anzahl der korrekt ausgelesenen Sektoren übersteigt. Ja Sektoren. Die Platte kann den gesamten Sektor nicht wiederherstellen, nicht nur 1 Byte.

Ein Rebuild umfasst das gesamte RAID. Wie voll das Laufwerk ist, weiß nur das Dateisystem, nicht der Controller, der eine Stufe tiefer agiert.

Der unlesbare Sektor muss mitnichten Paritätsdaten enthalten. Wenn der Fehler in einem gesunden R5 auftritt, wird er aus Paritätsdaten wiederhergestellt, bzw. die Paritätsdaten werden neu geschrieben. Wieviel Daten dafür von den Platten neu eingelesen werden müssen, hängt vom Controller ab. Fällt dir eine Platte aus, UND beim Rebuild tritt ein URE auf (die rechnerische Wahrscheinlichket liegt bei 7 Platten à 2TB bei 100%), dann ist es scheiß egal, ob der Sektor Paritätsdaten oder Nutzdaten enthält, dann hast du ein Problem. Manche Controller setzen das Rebuild fort (und markieren den Sektor anschliessen als "bad"), manche brechen ab.
 
Es geht nicht darum, dass 2TB Platten Alltag sind

Meine Aussage "der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute)" war natürlich nur beiläufig und sollte bloß klarmachen das die Ansicht die der Autor vertritt, nämlich das 2TB Platten 2009 Alltag sind, und deswegen Raid 5 ab 2009 nicht mehr sicher ist, beschränkt ist, da andere leute anhand solcher Artikel planen.


Ein Rebuild umfasst das gesamte RAID. Wie voll das Laufwerk ist, weiß nur das Dateisystem, nicht der Controller, der eine Stufe tiefer agiert.

Völlig wurscht, erklär mal warum ein Raidcontroller Daten von einem defekten Sektor wiederherstellen soll mit dem gar nicht gearbeitet wird, weil einfach keine Daten drauf liegen.
Ich will damit nur sagen das man keinen Datenverlust wegen defekten Sektoren hat wenn auf diesen Sektoren gar keine Daten liegen.
 
Zuletzt bearbeitet:
Die Flutkatastrophe war ende 2011 und hat nichts damit zutun das 2tb platten in 2009 lange nicht "alltag" waren...
Ich bezog meinen Kommentar ja auch auf deine Aussage, daß sie es heute noch nicht sind ;)
Vor ungefähr einem Jahr nämlich hatten 2TB-Platten das beste GB/Preis-Verhältnis..

Grüße
 
Meine Aussage "der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute)" war natürlich nur beiläufig und sollte bloß klarmachen das die Ansicht die der Autor vertritt, nämlich das 2TB Platten 2009 Alltag sind, und deswegen Raid 5 ab 2099 nicht mehr sicher ist, beschränkt ist, da andere leute anhand solcher Artikel planen.
Der Autor hat rechnerisch bewiesen, dass ab einer bestimmten Kapazität RAID 5 nicht mehr sicher ist. Ist Mathematik nun beschränkt :fresse: ?

Völlig wurscht, erklär mal warum ein Raidcontroller Daten von einem defekten Sektor wiederherstellen soll mit dem gar nicht gearbeitet wird, weil einfach keine Daten drauf liegen.
Ich will damit nur sagen das man keinen Datenverlust wegen defekten Sektoren hat wenn auf diesen Sektoren gar keine Daten liegen.
Weil der RAID-Controller nicht weiß, ob da was drinnen steht oder nicht. Der schreibt einfach nur Blöcke, die er vom OS geliefert bekommt zusammen mit Paritätsdaten auf die Laufwerke. Was da drinnen ist interessiert ihn überhaupt nicht. Wurde aber schon erwähnt...
Es hat schon seinen Grund, warum Sun ZFS entwickelt hat - mit dem Merkmal, dass einer Festplatte nicht zu vertrauen ist.

Die Diskussion passt allerdings nicht in den Bilderthread und die Mods werden das hier nicht gerne sehen...
 
Der Controller (jedenfalls die LSIs) schreibt beim Rebuild jeden Block auf die neue HDD. Das bedeutet im Falle von R5, dass mit 100% Wahrscheinlichkeit bei dem hier besprochenem R5 ein URE auftreten wird. Es kann sein, dass der Controller weitermacht, es kann jedoch sein, dass er Dir den Rebuild abbricht. Die Folge ist ein Fehler auf dem Array der sich nicht mehr beheben lässt.


R6 ist genau deswegen der Nachfolger. Der Vorteil, dass sogar zwei HDDs ausfallen können ist eher nen Nebengimmik bzw im "Notfall" hat man dann auch Fehler jedoch ist nicht alles fricke. Es ist im Grunde bei 2TB-Disks und R6 ebenfalls nur eine HDD ist, wenn man keine korrupten Daten haben möchte.

Das Ganze lässt sich nochmal abrunden wenn man auf R60 geht (wenn es viele Disks sind) so beschränkt man die wiederherzustellende "Menge" an Daten.

Wenn man sich das Problem mal vor Augen führen möchte lasse man einfach einige Zeit Patrol Read laufen. Wenn "Unexpected Sense on PD... blabla) auftritt hat man UREs dabei, die sich aber durch nen Consistency Check beheben lassen. Fällt jeodoch ne Platte aus war es das mit der Behebemöglichkeit.
 
Ich kann mich irren, aber ich glaube das defekte Festplatten weniger oft die Ursache für ein defektes Raid sind als viele denken

Also die Aussage finde ich einfach Klasse!!!
Wie heisst es so schön: "Irren ist menschlich!"
Die Aussage ist sogar weitgehend richtig, wenn man bedenkt, daß die meisten Raids erst beim Rebuild sterben.....
 
Zuletzt bearbeitet:
aus nem anderen Forum:

Original von Snipa
noch ne generelle Frage zum Topic: "Error rate (non-recoverable, bits read) 1 in 10^14" <-- wegen dem sagen manche, dass man bei RAIDs von >10TB nicht auf RAID5, sondern RAID6 setzen sollte. was meint ihr dazu? ist das Humbug?

Original von PERSON A
Ja das ist Humbug, da die Fehler sogenannte "silent corruption" auslösen, der Raid-Controller erkennt solche Lese/Schreibfehler gar nicht, da er die CRC Summe nicht überprüft sondern einfach schön seine Bits verteilt. Wenn er meint das er 1 geschrieben hat und alle 1x10^-14 Bits tritt eine 0 auf dann ist da halt eine 0, da hilft nur die Fehlerkorrektur des Dateisystems die in 99,99% diesen Fehler erkennt und repariert wenn darauf zugegriffen wird. Eine andere Lösung wär Raid-Z mit ZFS zu verwenden, das ist jedoch eine Softwarelösung die die CRC Summe zurückliest um zu überprüfen ob die Daten richtig geschrieben wurden.

Original von PERSON B
Nö, ist es nicht. Alle grossen Storage Hersteller Empfehlen RAID6 mit SATA, schon nur wegen der TTR (mean time to recover). Den Fehler hättest du mit RAID6 ebenfalls, aber wie gesagt, die Empfehlung kommt nicht wegen dem.
Hast du irgendwo im grossen Stil RAIDZ mt ZFS im Einsatz?
 
@Snipa: Das was Person A da behauptet, trifft nur zu, wenn die Platte bei einem URE einfach ein "falsches" Bit zurückgibt. Dem ist aber NICHT so.
 
Genau die Gedanken hab ich auch gehabt (und den Bericht dort gelesen), deswegen werkeln bei mir nun 2x RAID6 die ich (unregelmässig) nochmal extern sichere (zumindest das "wichtige").
 
die Chance für Datenverlust durch einen einzigen Sektor-Fehlers im raid-5 array mit n Platten nach einem Plattenausfall liegt bei
(n - 1) * Diskkapazität[in Bit] / Bit Error Rate [der verwendeten Platten]

sei ein raid-5 array aus 10 Platten á 1TB mit einer BER von 10^14, mit welcher Wahrscheinlichkeit tritt dann ein Lesefehler während eines Rebuild (nach dem Ausfall einer ersten Platte) ein?
1TB = 8 * 2^40 bits, ausgedrückt in Potenzen zur Basis 10 sind das 8,79 * 10^12 bits
da für einen Rebuild sämtliche Sektoren aller verbliebenen 9 Platten gelesen werden müssen, ergibt das eine Menge von 79,16*10^12 oder 7,9*10^13 zu lesenden Bits
beträgt nun die Lesefehlerrate (wie bei low end platten üblich) 10^14, dann ergibt sich 7,9*10^13/10^14 also 79% Chance, dass während des raid-5 rebuild durch Lesefehler Daten oder das ganze array verloren gehen

für 2TB Consumer Platten mit 10^14 BER sieht es wie folgt aus
2TB in 10er Potenzen ausgedrückt sind 17,59*10^12
10^14/17,59*10^12 = 5,7; i.e. bei Verwendung von 5,7 Platten dieses Typs tritt nahezu zwingend ein Lesefehler während des Rebuilds ein

bei Nearline Platten á 2TB mit 10^15 BER tritt, wie man nun leicht selbst überprüfen kann, mit an Sicherheit grenzender Wahrscheinlichkeit erst bei Verwendung von 56 Platten dieses Typs ein Fehler dieser Art ein

was also kann man tun, 4 Dinge, würde ich sagen:
* für aktuelle Backups sorgen
* anständige Festplatten verwenden mit besseren BER, bei grösseren Platten im Sata-Bereich sind das die sog. Nearline Platten, zb. Constellation ES
* in der Formel oben an dem Parameter n drehen, um die Wahrscheinlichkeit für nicht korrigierbare Fehler während des rebuild eines raid-5 zu reduzieren;
das ist es nämlich, was raid-50 tut, und dennoch grössere Datenmengen handeln kann als ein raid-5 allein
für raid-50 bleibt allerdings immer noch das Problem eines möglichen zweiten Plattenausfalls, besonders bei low end platten
die Gesamt-Verlässlichkeit, bzw. umgekehrt die Chance auf Datenverlust eines solchen Arrays bestimmt sich bekanntlich aus den drei Grössen MTTR, MTBF und BER
für die Verlässlichkeit eines raid-5 gilt: MTBF^2 / (n * (n - 1) * MTTR), wobei n Anzahl der Platten
eine seriöse, und insoweit vorsichtige rechnerische Annäherung an die Problematik berücksichtigt aber natürlich die in der Praxis zu beobachtende Neigung von arrays nach einem ersten Plattenausfall im Rebuild gleich noch einen zweiten Ausfall nachzuschieben; ein raid-5 und ein raid-50 sind dann tot. Solche sogenannten korrelierten, nämlich von den Umständen abhängigen Plattenausfälle, deren Eintrittswahrscheinlichkeit eben nicht mehr entlang der statistischen Ausfallwahrscheinlichkeit der einzelnen Platte verläuft, werden dergestalt berücksichtigt, dass für eine weitere (zweite) eine 10mal höhere Wahrscheinlichkeit und für eine weitere (dritte) Platte eine 100mal höhere Ausfallwahrscheinlichkeit zugrunde gelegt wird
es ergibt sich so folgendes:
-raid-5 = MTBF * MTBF/10 / n * (n - 1) * MTTR
-raid-6 = MTBF * MTBF/10 * MTBF/100 / n * (n - 1) * (n - 2) * MTTR^2

* raid-6 verwenden, damit erschlägt man gleich mehrere Probleme,
ein Lesefehler im Rebuild macht nämlich einem raid-6 gar nichts, die Daten sind wegen der zweiten Paritätsschicht allemal rekonstruierbar
und auch ein zweiter Plattenausfall führt nicht zu irgendeinem Datenverlust
 
Und genau deshalb bin ich z.B. von einem Perc5i (toller Controller nach wie vor) jetzt bei einem Areca1261ML mit 14Tb brutto und 10Tb netto im R6.Die wichtigsten Daten sind auch noch sep. gesichert.
Die Constellation ES ist klasse, alledings schon heftig teuer, aber gut der Areca hat auch keine 4,50Euro gekostet :)
 
@dv2130n: sehr schön beschrieben. ;) Genau das ist der Grund warum man ab 1TB auf R6 gehen sollte. Ggf mit vielen Platten vielleicht sogar auf R60 (wobei wer betreibt hier als privater User mehr mehr als 8 HHDs in einem Array!?). Ich hab im Umkehrschluss auch am verbleibenden Perc 5i nur 500GBer RE4s mit 10^15 als R5 laufen. So läuft das Rebuild (dank Hotspare) ebenfalls schnell über die Bühne und UREs sollten ein kleineres Problem sein.

Wenn die HDDs im mom nedd so teuer wären würd ich aktuell auch auf 2TB@R6 aufrüsten. Meine Favs sind derzeit die FAEX (ich tippe auf RE4 nur mit anderem Label und FW) oder RE4s.

Wer sich damals an die Diskussion erinnert: Dort stand bei den meisten HDDs noch 10^4. Plötzlich über Nacht quasi wurde 10^5 draus. Ich wäre deshalb etwas vorsichtig! Ob diese Angeben wirklich überprüfbar sind? Aus der Praxis geh ich eigentlich von öfteren Lesefehlern (siehe Unexpected Sense) aus - insbesondere wenn es Consumer-Platten sind.
 
Zuletzt bearbeitet:
naja, wobei R60 schon etwas overkill ist, oder, auch wie Du sagst vom reinen HW Einsatz....
Ich bin der Meinung R6 und dann eine ColdSpare im Schrank reichen für uns "normalerweise" aus. R6 + HS + CS ist schon irgendwie Paranoia :)
 
bei mir laufen 2x RAID 6 mit jeweils 6x Hitachi 7K3000 bisher ohne weitere Probleme.

Gesichert wird über Infiniband 10GB auf einen 2. Server (wird von Strom und Netzwerk getrennt nach Sicherungen), der auf 2x RAID5 läuft (10TB Arrays). Eine Coldspare im Schrank hab ich bisher nicht, wenn auf dem RAID6 mal was ausfällt, wird halt kurzfristig Ersatz besorgt, die Daten sollten also soweit halbwegs sicher sein.

Und mehr Aufwand als Homeuser wird dann doch übertrieben (ist es eigentlich jetzt schon :) )
 
nicht gleich hauen wenn ich es jetzt falsch verstehe, auf was ist diese "unrecoverable read error rate" bezogen? Auf das komplette Raid oder pro festplatte? Und dieser Fehler kann vorkommen muss aber nicht? Wenn es nun pro Festplatte diese Rate gibt, dann dürfte es doch eig kein problem sein, denn pro platte werden doch beim rebuild max 2TB gelesen oder irre ich da jetzt?
Ggf kann ja mal jemand aufklären und verbessern falls ich falsch liege!
 
@popel88:

Also ich habe das so verstanden, dass es pro Platte ist. Und je nachdem welche Error-rate deine platten haben geschieht das halt öfter oder nicht.

Error Rate
10^14 bits --> 12.5TB
10^15 bits --> 125TB
10^16 bits --> 1.25PB

LINK ZUR TABELLE. D.h. also bei einer "schlechten" platte passiert so ein fehler von 1 bis 10^14 Bits (also im Schnitt bei 12,5TB gelesenen Daten)
und bei einer "guten" platte erst bei ~125TB oder sogar 1.25PB.
-----------------------
Ich habe aber mal eine andere Frage:
Wie auch auf diesem Link zu sehen, steht dort, dass manche Raid-Controller diesen Fehler wärend eines Rebuilts einfach "überspringen" , was dann (NUR) zum Datenverlust dieser Datei führen würde, oder halt den Rebuilt abbrechen, weil der Raid-Controller dann denkt, dass noch eine Platte kaputt ist und den Rebuilt-Prozess abbricht.
Jetzt meine Frage: Wisst ihr was die LSI Megaraid-Controller an dieser Stelle machen? ( Ich hab den Megraid 9260-4i, obwohl das ja egal sein müsste, welcher MegaRaid von der 9xx-Serie).
Brechen die LSI-Kontroller den Rebuilt-Vorgang ab oder markieren sie diese Datei einfach als Fehlerhaft?

(Ich hab nämlich 3x3TB WD-Platten als Raid5 :( )
 
Zuletzt bearbeitet:
Hrhr...jetzt kommen wohl einige ins Schwitzen, die eine ähnliche Konfiguration haben... ;) Mal schauen, ob ich das richtig verstanden habe: So ein "URE" tritt pro Platte alle 10[SUP]14[/SUP] Bits (normale Platten) bzw. alle ~12TB gelesener Daten bei dieser Platte auf. Dieser "URE" kann von der Platte selbst nicht korrigiert werden und muss durch die Parität des Raids ausgeglichen werden. Wenn dies nicht möglich ist, geht das Raid "hops". Das hieße also, wenn beim Raid5 eine Platte ausgefallen ist und ein "URE" bei der Wiederherstellung auftritt ist das Raid futsch. Es spielt auch keine Rolle, ob das betreffende Bit beim "URE" Informationen enthält oder nicht, da bei einem Rebuild die komplette Platte "abgelesen" wird. Soweit richtig..?

Wenn das so stimmt, täte mich an dieser Stelle interessieren, ob man das irgendwie so beeinflussen kann, dass man diesen "kritschen Punkt", sollte es einer sein, "überspringt". Es dauert zwar eine Weile, bis man 12TB gelesen hat, aber in einem Festplattenleben, gerade bei den großen Platten jetzt, kommt das sicherlich einige Male vor. Als nächstes ist es doch so, dass bei einem Raid5/6 die Festplatten alle gleichmäßig gefüllt werden. Das heiße ja also auch, dass man, wenn man ein Raid5/6 mit nagelneuen Platten erstellt, alle Platten nahezu dieselbe Datenmenge lesen/schreiben. Da ist es ja eigentlich so gesehen schon vorprogrammiert, dass sie alle zur selben Zeit an diesen Punkt kommen und wenn dann eben zufälligerweise beim Raid5 noch eine Festplatte ausfällt... Da wäre das Raid6 auch nur noch durch die zweite Paritätsfestplatte im Vorteil...

dv2130n: Hast du für die Formeln mal die Quelle da, würde das gerne noch mal "unvorbelastet" nachvollziehen wollen, gerade was das Abwägen von Raid5/6 betrifft...
 
@andichen:
In dem Link steht ja.."drives will simply fail to see data due to some kind of error. Doesn’t matter what the cause of this error is, " --> bedeutet, dass der Kontroller halt einfach einen Fehler beim Lesen hat, bzw. die Festplatte ein Lesefehler hat und dem Kontroller nicht das gewünschte Datei-Fragment (bzw. null oder eins) liefert, sondern halt irgendwas anderes, sodass ein Fehler auftritt.

Und Ich denke nicht, dass das bei allen Platten genau nach 12,5TB passiert. Dort steht ja dass es im Schnitt alle 1-10^14 gelesenen Bits (normale Platten) zu einem Fehler kommt.
 
Zuletzt bearbeitet:
bogomil22: Danke erst mal für den Link. *) Der hat wenigstens Zusammenhang und ist nicht so "fragmentiert" wie der von Slashcam bzw. das Original davon, was ja schon wie "Weltuntergang" geschrieben ist. Es ist also tatsächlich so, dass dieser "URE" pro Festplatte irgendwann zwischen dem 1. und 10[SUP]14[/SUP]. gelesenen Bit auftritt. Das ist natürlich Knete... und bedeutet, dass die Eintrittswahrscheinlichkeit des "URE" steigt, je mehr Platten im Raid sind, ja sogar je größer die Festplatten selbst sind.

Da ist es natürlich von Interesse, wie ein Controller bei sowas mit der Angelegenheit umgeht. Man kann ja "Glück" haben, dass es kein Datenbit betroffen ist und es für die gespeicherten Informationen belanglos ist. Schließe mich der Frage an... ;)

popel88: Das sollte deine Frage beantworten: Dadurch, dass die Platten alle über das Raid "zusammengeschaltet" sind, ist es egal, bei welcher Platte der "URE" auftritt. Das macht die Sache so "gefährlich"...

*) Sehr lustig übrigens: "Without other action, this would be the “all your data is belong to us,” or the better known as “pray you have a backup of either all of the data, or at least your resume” problem." :d
 
Zuletzt bearbeitet:
Wie auf der verlinkten Seite von bogomill22 so schön steht:
The Seagate Barracude ES and ES.2, WD’s latest drives, and the Hitachi Ultrastar line are all 10^15 error rates.
War das damals auch mit ein Grund eine ES.2 zu kaufen und im Raid10 zu benutzen. Seagate hatte eine Präsentation auf der SNIA schon 2005 und das Problem von URE bei einem Raid5 rebuild angesprochen. Das Thema ist also nun schon über 6 Jahre alt!
Für Leitungscodierung wird z.B. eine Fehlerrate von 10^12 übertragenen Bits angenommen. Damit muss die Leitungscodierung fertig werden.
Festplatten speichern neben anderen Daten für jeden Sektor noch ECC Informationen. Sollte ein Sektor nicht wiederhergestellt werden können nach der max. erlaubten Zeit (1,x Sekunden - näheres steht im richtigen Datenblatt mit Angabe in ms) wird dieser als fehlerhaft gemeldet. Einige Raidcontroller haben darauf hin die ganze HDD als defekt markiert und ein Raid deswegen oft degraded.
Wenn man von der Statistik ausgeht, wo zum Beispiel auch gerne beim Passwort raten man von 50% der zu untersuchenden Kombinationen (Brute Force) von einem Erfolg ausgeht - ist die Wahrscheinlichkeit analog dazu bei HDDs auch schon bei der Hälfte an gelesenen Daten einen unkorrigierbaren Sektor zu erhalten.
 
Zuletzt bearbeitet:
Na ja...das ist ja alles toll, wenn man das schon vor 6-7 Jahren wusste...was ist aber diesbezüglich passiert? NIX! Mittlerweile säuseln 3TB-Platten mit der "herkömmlichen" Fehleranfälligkeit von 1 in 10[SUP]14[/SUP] Bit vor sich her. Darüber, dass Seagate mit der 3TB-Platte mit inzwischen nur 1-jähriger Herstellergarantie u.a. als "optimalen" Einsatzzweck "Desktop-Raid-Systeme" vorsieht, könnte ich mich scheckig lachen, wenns nicht so ernst wäre. Es ist schon ziemlich ärgerlich, das über sowas die "Produktklassifikation" gemacht wird. Leider liegt das grundlegende "Problem" dafür ganz woanders... Man kann sogar unterstellen, dass es gewollt ist, dass deswegen viele auf Raid6 setzen/umsteigen und so wieder mehr/zusätzliche Festplatten verkauft werden können... Höchstwahrscheinlich wird dann auch die Qualität der Garantiezeit "angepasst" werden, denn man weiß ja: "Was ewig hält, bringt kein Geld..." Schlimm, dass es offenbar nicht anders geht...

Wenn ich mir im Laden was aussuchen könnte, würde ich natürlich auch nur die geeignetsten Produkte wählen, leider kann ich den Laden damit nicht verlassen, ohne sie vorher entsprechend bezahlt zu haben...

Statistik ist ja schön und gut, aber letztlich ist es mMn auch nur berechnetes "Lotto". Wieviel jedem seine Daten wert sind, muss wohl jeder selbst festlegen. Dafür muss man aber natürlich auch die möglichen Gefahren kennen, beurteilen und schließlich abwägen können. Das ist schon die halbe Miete, würde ich sagen...
 
Na ja...das ist ja alles toll, wenn man das schon vor 6-7 Jahren wusste...was ist aber diesbezüglich passiert? NIX! Mittlerweile säuseln 3TB-Platten mit der "herkömmlichen" Fehleranfälligkeit von 1 in 10[SUP]14[/SUP] Bit vor sich her.

naja, was willst du denn genau? dass die Hersteller bei Desktop-Festplatten einfach mal alles auf 1 in 10[SUP]15[/SUP] Bit ändern/umstellen? jeder will 2TB-Festplatten für 70eur ... oder noch besser: für nen Fuffi oder weniger. anstatt Platten mit 1 in 10[SUP]15[/SUP] Bit zu kaufen, lieber meckern, dass Qualitätsware zu teuer ist? jeder will Qualität, aber nicht dafür bezahlen. ist beim Fleisch genauso. jeder will Fleisch von glücklichen Tieren ausm Bauernhof mit Auslaufhaltung, aber bezahlen will man nur soviel, dass für die Mastbetriebe nur die Käfigbatterien rentieren.

man könnte ja sonst auch sagen: RAID 6 gibts schon viel länger als die bekannte Problematik. nutze die Möglichkeiten :p
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh