[Guide] Unterschied von normalen und "Enterprise grade" HDDs

[bluesunset]

Da die Erklärung von gestern leider fehlt, der Versuch hier als extra Thema.

[1]http://download.microsoft.com/downl...4e74-92a3-088782200fe7/twst05005_winhec05.ppt Eine der ersten Versionen als Powerpoint Präsentation

[2]http://www.snia.org/sites/default/e...torage/WillisWhittington_Deltas_by_Design.pdf 2,2 MiB - bis Herbst diesen Jahres online
sowie die letzte gekürzte Version [3]http://www.snia.org/sites/default/e...ington-W_Desktop_Nearline_Enterprise_HDDS.pdf sechs Monate länger online.

Ich gehe mal nur auf die letzte Version ein, da für einige die älteren Versionen wohl schon zu lange her sind.

Seite 6 ist eine Gegenüberstellung der aktuellen Marktüblichen Unterteilung von Festplattenmodellen in bestimmte Kategorien. http://www.hardwareluxx.de/communit...1tbyte-plattern-und-64mbyte-cache-874154.html zeigt leider auch, dass der Trend von Desktopmodellen wieder hin zu unzuverlässigeren Modellen mit einer URE von 10^14 und einer jährlichen Laufleistung von max. 2400 Betriebsstunden ist.
Bei der max. MTBF ist man hingegen schon bei 2 Millionen Stunden angelangt und bei einer AFR < 0,4% (jährliche Ausfallrate) - ist hier nicht vermerkt.

Seite 17 ist eine Gegenüberstellung der Laufwerkselektronik von SAS und SATA Laufwerken, für diejenigen die sich wundern, warum Nearline-Modelle welche mit beiden Schnittstellen erhältlich sind unterschiedlich viel kosten.

Seite 23 und 24 der Einfluss von Rotationsvibrationen. Die 33 verschiedenen (Wechsel-) Rahmen wurden von Seagate im Jahre 2005 herum getestet. Damals stellte sich heraus, dass 11 davon nicht einmal für die besonders toleranten 10 und 15k SAS-Laufwerke geeignet sind. In der Version von 2005 ist die rede von Enterprise Cabinets.
- Mit ein Grund warum ich den billigen 100 Euro SATA-Wechselrahmen 4x3,5" in 3x5,25" aus Alu und Plastik nicht vertraute , welche seit damals erhältlich sind.
Bei einem stabilen Stahlgehäuse vibriert so gut wie nichts. Da sind dann zum teil SAS-Laufwerke leiser als 7200 rpm SATA HDDs in den 40 Euro Blechgehäusen.

Seite 26 und 27 was es mit der URE auf sich hat, und warum man kein Raid 5 mit entsprechenden 3TByte Laufwerken machen sollte - bei fünf Laufwerken ist nahezu 100% ein Lesefehler bei einem Rebuild dabei.
*Edit*

Rebuilding a SATA drive in a RAID 5 set of 5 drives means transferring 5/25 x 10^14 bits

500GB Laufwerke, mit Raid5 aus 5 Laufwerken sind wohl 5 verbliebene (degraded Zustand) von denen die Daten gelesen werden. Nach einem (hoffentlich) erfolgreichen Rebuild enthält das Raid5 wieder 6 Laufwerke!


Seite 29 und 30 wie man durch eine geänderte Codierung der Nutz- und ECC-Daten eine höhere URE erreichen kann.

Seite 31 und 32 wie man mithilfe von einer zusätzlichen Syncronisationsmarkierung einen Sektor dennoch auslesen kann, wenn der Anfang nicht mehr lesbar ist bzw. das Laufwerk den Schreib-/Lesekopf nicht richtig positioniert hat. Dieses Feature ist eher nur bei 10k und 15k SAS-Laufwerken anzutreffen und dürfte mit ein Grund für eine URE von 10^16 sein - neben IOEDC ->

Seite 34 ist ein Diagramm mit IOEDC/IOECC, hierzu müsste es noch eine alte Erklärung geben, in der Version vom Herbst 2007 ist dies auf Seite 44 in einem anderen Diagramm etwas einfacher aufbereitet. Seite 43 ist in der neueren Version leider entfernt worden.

Seite 40 ist ein Bezug zur höheren AFR wenn man Desktoplaufwerke 24/7 unter Last laufen lässt.
In der Version von 2005 sind auf Seite 15 und 16 die typischen Belastungen aufgeführt.
Seite 21

3 groups of 300 Desktop drives were tested in commercial test chambers

Es handelt sich demnach um 900 (S-)ATA Laufwerke.
Bei den 300 Laufwerken mit einer normalen Desktopbelastung wurde der test nach 1000h abgebrochen, da anscheinend keine höhere Ausfallrate mehr eingetreten ist.
Ähnlich wie beim Test von 300 Laufwerken mit mittlerer Auslastung, wo die Ausfallrate nach 1000h ca. 4% beträgt.
Bei den 300 Laufwerken die der höchsten Belastung ausgesetzt wurden, beträgt die Ausfallrate nach über 1100h mehr als 7%.

Da neuere Laufwerke wie zuvor schon auch SCSI/SAS Laufwerke die geschriebenen und gelesenen Datenblöcke aufzeichnen, wird der Hersteller bei etwaigen Garantieansprüchen diese ggf. ablehnen. Sofern der Benutzer das Laufwerk außerhalb der zugelassenen Parameter betrieben hat. Die max. erreichte Temperatur wird schon länger mit aufgezeichnet und beträgt je nach Modell (bisher) 55°C oder 60°C.
Und bevor es hier zu einer Diskussion kommt: Es ist die rede von der freiwilligen Herstellergarantie, nicht von der gesetzlich vorgeschriebenen Gewährleistung gegenüber dem Verkäufer.


Zusammenfassung
Die Hersteller unterscheiden aktuell vier Kategorien:

Desktop SATA 5400-7200 rpm, welche (meistens) keine 24/7 Freigabe haben und eine URE von 10^14.
Preis vor der Überflutung ca. 3-5 Cent/GB

"Nearline" SATA 7200 rpm, mit 24/7 Freigabe unter geringer Last und einer URE von 10^15 für Raid-Betrieb auch an Hardwarecontrollern.
Preis vor der Überflutung ca. 10 Cent/GB

"Nearline" SAS-Laufwerke 7200 rpm, ansonsten gleiche Angaben wie Nearline SATA Disks.
Preis vor der Überflutung ca. 12-15 Cent/GB

"Enterprise" SAS 10k/15k rpm für 24/7 Betrieb unter hoher Last und einer URE von 10^16.
Preis vor der Überflutung ca. 60 Cent/GB für ein 3,5" Modell mit 15k rpm


Als bisherige Außnahme gibt WD sogar 10^17 als URE an. Siehe nächsten Post.

 

[antilope114]

Danke für den Link. Gute Übersicht.

Habe gestern gesehen, dass die WD S25 10k Laufwerke eine non-recoverable error rate von <10^17 haben, das scheint aber ein Alleinstellungsmerkmal der WDs zu sein

http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-771379.pdf

 

[bluesunset]

Interessant, vor allem da WD bei diesem Modell auch in zwei Kategorien unterteilt:
Das 600 und 450GByte (BKHG) Modell haben eine MTBF von 1,75 Millionen Stunden, einen Cache von 32MiB, eine max. Übertragungsrate von 155MByte/sec und 600k Parkvorgänge

Während die 300 und 147GByte (BKFG) Modelle eine MTBF von 1,6 Millionen Stunden, einen Cache von 16MiB, max. Übertragungsrate 126MByte/sec und nur 50k Parkvorgänge kann.

Beide Modelle haben aber die Einschränkung im Temperaturbereich von 5°C bis max. 55°C (Desktop Laufwerke). Normal sind bei solchen Laufwerken eher 0°C bis 60°C. Was vielleicht auch für die etwas höhere URE von 10^17 spricht. Gerade der Bereich von 60°C herum ist da sehr abträglich was ein zuverlässiges Schreiben der Daten anbelangt.

Ich hoffe mal das HAMR (Heat-assisted magnetic recording - von Seagate im Jahre 2005 für das Jahr 2012 voraus gesagt) bald kommen wird. Zumindest bei 3.5" und 15k RPM steht man schon seit einiger Zeit bei max. 600GByte still, während 10k 2.5" Disks schon bei 900GByte sind.

 

[antilope114]

Bei den 2,5" 10/15k drives ist der Temperaturbereich von 5-55° bei einer UER von 10^16 eher die Regel (so auch bei Savvio 15K.3/15K.2, Hitachi C10K600 bzw. der neuen C10K900).
Im Gegensatz zur WD haben die meisten anderen allerdings eine MTBF von 2Mio. Std. (wobei man wohl bei kleinen Festplattensamples über die Aussagefähigkeit der MTBF streiten kann...)

Die UER ist dann doch die aussagekräftigere (wichtigere?) Kennzahl.

Die Angabe der Maximalen Parkvorgänge bei der WD S25 irritiert mich aber etwas, kann das nicht wirklich einordnen. Subjektiv würde ich sagen, 50k sind nicht viel für ein solches Laufwerk. Kann mich aber irren.

 

[bluesunset]

Kommt immer darauf an, welche Zeit das Laufwerk abwartet bis es die Köpfe parkt bzw. ob dieses Feature auch aktiviert ist.
Bei einem Einsatz in einem SAN als Raidlaufwerk welches mehrere LUNs zur Verfügung stellt dürfte die Festplatte so gut wie nie in die Versuchung kommen während der Geschäftszeiten sich auszuruhen.

Hrm, anscheinend haben alle neueren SAS Laufwerke die Einschränkung von 5-55°C. Nur bei den Modellen mit 7200 rpm und 3.5" liegt sie bei 5-60°C. Meine ES.2 waren noch für 0-60°C spezifiziert.

Im Datenblatt für eine 2.5" SCSI von 2007:

The maximum allowable continuous or sustained HDA case temperature for the rated MTBF is 122°F (50°C)

The maximum allowable HDA case temperature is 60°C. Operation of the drive at the maximum case temperature is intended for short time periods only. Continuous operation at the elevated temperatures will reduce product reliability.

Hier waren auch 5-55°C Umgebungstemperatur angegeben.
Als Fazit kann man wohl nur sagen, Festplatten sollten unter 50°C warm werden (40°C ist wohl die "Wohlfühl"-Temperatur).

Bei der URE lag das 2.5" SCSI Laufwerk noch bei 10^15 bei einer MTBF von 1,4 Millionen Stunden. Nebenbei noch

Miscorrected Data - Less than 1 sector in 10^21 bits transferred

10^17 Bits sind 12500 TByte
Bei angenommenen 100MByte/sec tritt ein Fehler alle 12500 TByte/0,0001MByte/sec = 125000000 Sekunden auf.
125.000.000 Sekunden / 60Sekunden / 60 Minuten / 720 Stunden pro Monat ~ 48,225 Monate.
Also ein Fehler alle vier Jahre. Demnach dürfte solch ein Laufwerk während seiner 5 jährigen Einsatzzeit so gut wie niemals einen URE haben.
Die Praxis wird es zeigen.

 

[Digi-Quick]

Also bei einer URE von 10^14 tritt ein URE statistisch gesehen alle 12,5 TB auf.

Ich nehme ein Raid 6 aus 8x 3 TB = 18 TB, dann darf ich kein Backup ziehen, weil dann statisch gesehen bereits eine Platte während des Backups rausfliegt, eine 2. Platte während des rebuilds und schlussendlich die 3 Platte während des letzten Rebuilds.


Selbst bei eine Raid 6 aus 8x2 TB ( = 12 TB) habe ich schon das gleich Problem.....

Mein Kommentar dazu: gleube nie einer Statistik, die du nicht selbst gefälscht hast- ich habe ja auch ein wenig "geflunkert - die Daten werden ja über mehrere Platten gelesen....
Aber wenn ich dann noch automatische Fehlersuchen/ - Korrekturen wie Patrol Read und Konsistenzcheck dazunehme, stirbt so ein Raid in wenigen Monaten....

 

[popel1988]

wenn du ein Backup davon machst werden pro platte 3tb gelesen... Also ist die Wahrscheinlichkeit das es eintritt geringer.

 

[bluesunset]

1. kein Mensch baut freiwillig ein Raid 5/6 mit 8 HDDs aus entsprechenden billig HDDs zusammen.
Wenn es doch jemand ausprobieren will, Seagate hätte da was: Modellnummer ST3000DM001

2. solch ein Raid ist ein Backup, neben einem anderen System.

3. eine HDD kann man nie wirklich voll machen -> Dateisystem. Effektiv sind es ca. 80% die nutzbar sind ohne Geschwindigkeitsverluste.

Und ja, dein beschriebener Fall ist schon mal passiert.

 

[Digi-Quick]

1x Backup = 3 TB
Plus
4x PatrolRead oder Konstenzprüfung = 12 TB

Summe = 15 TB und damit schon drüber über der URE-Statistik

Wenn also dieser URE-Wert so entscheidend wichtig ist, sollte man also tunlichst auf Patrol-Read und Konsitenzprüfung im RAID verzichten, dann kann man auch gleich die On-Board-Controller nehemn, die haben diese Funktionen erst gar nicht - zumindestens bei Platten die nur 10^14 haben....

---------- Post added at 17:33 ---------- Previous post was at 17:23 ----------

3. eine HDD kann man nie wirklich voll machen -> Dateisystem. Effektiv sind es ca. 80% die nutzbar sind ohne Geschwindigkeitsverluste.

Und ja, dein beschriebener Fall ist schon mal passiert.

zu 3: 20 % von 3 TB wären 600 GB die nicht nutzbar wären - Never - wenn ich da 3GB frei lasse ist das genug

Zum letzten Satz: Ich habe es fast vermutet.....
Worst Case lässt grüssen - Shit happens - oder wie Mürphy sagen würde >> Alles was schiefgehen kann, wird auch schiefgehen

Auf jeden Fall wüsste ich jetzt gerne, wo denn nun die Hitachi Deskstar 5/7K2000 und 5/7K3000 einzuordenen wären
Laut URE von 10^14 als Desktop-Platten
oder wegen der 24/7 Freigabe für moderate Last als Nearline-Platten

 

[pajaa]

Helft mir mal. Angenommen, man hat ein RAID6 aus 8 3TB-Laufwerken mit einer Nennkapazität von 18TB, wo ein URE rechnerisch alle 12,5TB auftritt. Werden dann nicht automatisch die Paritätsdaten zur Wiederherstellung der Daten genutzt? Um die Ausfalltoleranz aber zu gewährleisten, muss es ein RAID6 sein, da das RAID5 in dem Fall ja schon die Parität nutzen muss, um die Daten der einen nichtdefekten Platte zu korrigieren.

Verstehe ich das richtig?

 

[Digi-Quick]

Meiner Meinung nach passt der URE nicht zur MBTF
URE 10^14 = 12,5TB
12,5 TB / 150MB/s = 23,15 h Lesbetrieb

die MBTF wird bei Hitachi nun nicht mehr angegeben, lag aber bislang eigentlich immer bei mehreren Jahren

 

[dv2130n]

...RAID6 ... Werden dann nicht automatisch die Paritätsdaten zur Wiederherstellung der Daten genutzt? ..

das ist richtig, intakten redundanten raid-arrays machen solche Festplatten-Lesefehler gar nix, die fehlenden Daten werden aus den Paritätsdaten rekonstruiert,
und zwar sowohl bei einem intakten raid-6 als auch bei einem intakten raid-5
darum ist die Lesefehler-Situation je nach raid-level erst kritisch, wenn eine erste Platte des array ausgefallen ist und der Lesefehler somit während des rebuild auftritt
ein raid-6 kann in dieser Situation den rebuild fortführen, weil die fehlenden Daten aus der zweiten Paritätsschicht rekonstruiert werden können
ein raid-5 kann da von sich aus nichts mehr rekonstruieren und ist dann meist, je nach Controller und je nach Verhalten des users, platt


und mtbf bezieht sich auf den Ausfall der ganzen Platte, bei einem dieser nicht korrigierbaren Lesefehler fällt aber deswegen nicht gleich die Platte aus,
wohl aber kann eine URE zu Datenverlust im raid-array führen, s.o.
mtbf und ure sind also verschiedene Einflussgrößen, die statistisch nichts miteinander zu tun, jedoch beide in die Gesamtfunktion zur Errechnung der Reliabilität eines raid-array insgesamt einbezogen werden müssen

 

[bluesunset]

http://www.usenix.org/event/fast08/tech/full_papers/jiang/jiang.pdf

... we analyzed the storage logs collected from about 39,000 storage systems commercially deployed at various customer sites. The data set covers a period of 44 months and includes about 1,800,000 disks hosted in about 155,000 storage shelf enclosures.

Seite 16 Diagramm rechts oben (b) RAID group failures zeigt, dass die AFR in der Praxis ca. dreimal so hoch ist.

Ein etwas kürzerer Test über 4 Wochen am Cern vor 5 Jahren: http://indico.cern.ch/getFile.py/ac...ionId=0&resId=1&materialId=paper&confId=13797

Running the verify command for the RAID controller on 492 systems over 4
weeks resulted in the fix of ~300 block problems. The disk vendors claims about
one unrecoverable bit error in 10^14 bits read/written. The 492 systems correspond
to about 1.5 PB of disk space. To get the real number of physical bits touched
during the process one has to include the fact that the data on disk contain an ECC
overhead (~17%) and that the ‘parity’ disk is also used, which leads to an increase
of 35%. Thus over 4 weeks in total
1.5 * 10^15 (bytes) * 1.35 (effective) * 8 (bits) * 4 (weeks)
~650 * 10^14 bits were read by the verify process.
During the same period about 200 * 10^14 bits were read/written by the applications.

Von den eigentlich zu erwartenden 850 Fehlern sind nur 300 aufgetreten. Die WD Platten hatten damals auch Probleme am 3Ware Controller. Aktuell sinds am LHC übrigens ~100PB jeweils als HDD und Tape.


Zum Befüllungsgrad von Festplatten:
Verwendest du NTFS? Nimm doch mal bitte ein passendes Tool, und wenn es O&O defrag ist und lass dir den vom NTFS-Dateisystem reservierten Bereich anzeigen.

 

[bogomil22]

Ist nun dieser URE-Fehler (ein unbekannter Lesefehler) in einem Raid-array das gleiche wie TLER? Oder sind das zwei unabhängige Fehler?

 

[Digi-Quick]

der von NTFS reservierte Beriech wird zum grössten Teil von der MFT belegt, diese wird zum einen für die Datenstruktur selbst verwendet (so wie die FAT) und zum anderen für die Speicherung kleiner Dateien, die weniger als einen Cluster (Zuordnugseinheiten) gross sind. beim Formatierern wird hierfür ein nicht unerheblicher Teil des Speicherbereiches reserviert (ca. 20 %), die verfügbare Datenträgergrösse wird aber nicht um diese Reservierung reduziert, da diese ersten dynamischt ist und 2. der Speicherplatz bereitsteht. wenn ich also nur Daten in Gigabytegrösse speichere, wird die Mft vordringlich fast gar nicht gebraucht, ausser für die Datenverwaltung - also entsprechend dynamisch verkleinert - ohne daß hier Nachteilke enstehen. Die performance wird dann beeinträchtigt, wenn ich nun bei einer fast vollen Platte Daten lösche, und kleiner Dateien raufpacke, da die MFT dann nicht mehr gross genug ist, um dies zu handeln - die MFT wird nicht dynamisch wieder vergrössert

 

[andichen]

Na ja...also wenn man diese PDF, es war ja mal eine Präsentation, mit einem kritischen Auge liest, fehlen doch ein paar, zumindest mMn, wichtige Infos. Kann natürlich sein, dass das dann mündlich erwähnt worden ist, aber so alleine ist das etwas dürftig... Beispielsweise ist dieser Abschnitt zum Schwingungseinfluss auf die Platten ziemlich undifferenziert. Bei den vielen verschiedenen Gehäusen bekommt man nicht mal gesagt, um welches es sich genau handelt und wie die Testbedingungen überhaupt sind. Dasselbe gilt für die Grafik von Auslastung zu AFR. Für mich liest sich das nämlich wie eine Werbung für Enterprise-Festplatten. Man darf ja auch nicht vergessen, dass der Autor für Seagate arbeitet...

Was ich aber nun gar nicht verstehe, ist, weshalb der gute Mann die URE-Wahrscheinlichkeit über die Brutto-Kapazität des Raid5 berechnet hat. Es wird doch nur die Netto-Kapazität gelesen, um die Parität wiederherzustellen. Ist euch das nicht auch aufgefallen..?

Wenn es nach Murphy ginge, würden ja alle Platten gleichzeitig ausfallen bzw. immer genau die Anzahl, die es braucht, damit das Raid auch nicht mehr helfen kann. Also meiner Meinung nach ist schon viel für die Platten getan, wenn man ihnen eine gute Betriebsumgebung bietet und sie, um Fertigungsfehlern o.ä. vorzubeugen, einlaufen lässt.

Vielleicht hat sich auch schon mal jemand die Frage gestellt, aber was passiert eig. bzw. was hat es zur Folge, wenn so ein URE bei einer einzelnen Platte auftritt?

 

[Digi-Quick]

Ich würde sagen "Datei xyz kann nicht gelesen werden" -
An dieser Stelle gehe ich davon aus, daß der Sektor dann als schwebend markiert wird (Current pending Sectors) und beim nächsen Oberflächenscan (Checkdisk /r) vom Defektmanagement der Platte als BAD markiert und durch einen Reservesektor ersetzt wird - sofern noch welche vorhanden sind.
Die entsprechende Datei kann man i.d.R. als defekt ansehen.

Und genau das sollte auch ein Raidcontroller in einem intakten Raid auch hinbekommen (Patrol Read entspricht hier dem Checkdisk /r).
Die URE Problematik greift daher eigentlich nur wirklich bei einem degradetem RAID, wenn die Paritäten neu berechnet werden.
heir kommt es darauf an, was der Raidcontroller bei einem URE macht
a) - das Rebuild wird mit Fehler abgebrochen, das Raid bleibt degradet
b) - das Rebuild wird abgebrochen und das RAID wird auf OFFLINE / FAILED gesetzt
c) - Das Rebuild wird fortgesetzt, mit einer entsprechenden Fehlermeldung, daß DATEI xyz beschädigt ist und nicht wiederhergestellt werden konnet
d) - die Platte mit dem URE wird auf Offline gesetzt, und das Raid ist zerlegt

ich denke mal, daß man der URE Problematik durch regelmässige Patrol reads und Konsitenzprüfungen (hier werden alle Daten und Paritäten auf Gültigkeit geprüft und ggf. korrigiert - entspricht weitestgehend dem CHKdSK /f) auf den RAIDs zuvor kommen kann - aber natürlich nicht ausschliessen kann.

 

[bluesunset]

Na ja...also wenn man diese PDF, es war ja mal eine Präsentation, mit einem kritischen Auge liest, fehlen doch ein paar, zumindest mMn, wichtige Infos. Kann natürlich sein, dass das dann mündlich erwähnt worden ist, aber so alleine ist das etwas dürftig... Beispielsweise ist dieser Abschnitt zum Schwingungseinfluss auf die Platten ziemlich undifferenziert. Bei den vielen verschiedenen Gehäusen bekommt man nicht mal gesagt, um welches es sich genau handelt und wie die Testbedingungen überhaupt sind. Dasselbe gilt für die Grafik von Auslastung zu AFR. Für mich liest sich das nämlich wie eine Werbung für Enterprise-Festplatten. Man darf ja auch nicht vergessen, dass der Autor für Seagate arbeitet...

Wenn es derjenige sagen würde, wärs ja einfach gewesen. Aber zur Erleichterung:
Damals wurden eher die ersten Wechselrahmen mit SATA, SAS sowie einige mit U320 und andere für FC-AL getestet. Ein Cabinet umfasst eher einen 3HE 19" Storageeinschub mit damals 14 oder 15 HDDs. Es sollte halt damit wohl auch darauf hingewiesen werden, dass die Gehäuse nicht für die weniger RV toleranteren SATA HDDs ausgelegt/getestet wurden.
Zumindest http://www.supermicro.nl/products/chassis/4U/417/SC417E16-RJBOD1.cfm gibt noch einen entsprechenden Hinweis über zu verwendende Festplatten.

SAS2, SAS, or enterprise SATA HDD only recommended

Wenn jemand meint, dass eine entsprechend billige HDD auch dafür tut oder in den bekannten QNap, Synlogic usw. NAS-Systemen, soll derjenige doch mal bitte einfach die entsprechenden Hersteller fragen: Ob es eine Freigabe für das gewünschte Modell bzw. generell entsprechende Desktop HDDs gibt.

Was ich aber nun gar nicht verstehe, ist, weshalb der gute Mann die URE-Wahrscheinlichkeit über die Brutto-Kapazität des Raid5 berechnet hat. Es wird doch nur die Netto-Kapazität gelesen, um die Parität wiederherzustellen. Ist euch das nicht auch aufgefallen..?

Die URE gilt nicht nur für Lese- sondern auch Schreibvorgänge.
Die URE gilt natürlich nur für Lesefehler, hatte damals zu viel im Handbuch gelesen...

Vielleicht hat sich auch schon mal jemand die Frage gestellt, aber was passiert eig. bzw. was hat es zur Folge, wenn so ein URE bei einer einzelnen Platte auftritt?

Im schlimmsten Fall ist ein komprimiertes Archiv betroffen, die Information für eine Partition (MBR usw.), das Dateisystem allgemein, irgend eine Prüfsumme oder einfach nur der Schlüssel für eine Dateisystemverschlüsselung - z.B. Windows EFS - und ohne Backup dessen alle Dateien nicht wiederherstellbar.
Mitlleres Problem für Endanwender: Benutzer macht Backup von 2/3 TByte HDD auf externe HDD mittels "Explorer". Der Kopiervorgang bricht mitten drin ab.
Im günstigsten Fall betrifft es einfach nur eine MPEG2-TS (Transportstream) Datei bei der die Redundanzdaten bzw. die Fehlerkorrektur den Fehler nicht sichtbar macht (ansonsten kurz eine Blockbildung im Bild wie bei DVB-[X]).

---------- Post added at 07:55 ---------- Previous post was at 07:25 ----------

Ist nun dieser URE-Fehler (ein unbekannter Lesefehler) in einem Raid-array das gleiche wie TLER? Oder sind das zwei unabhängige Fehler?

Die Frage ist verloren gegangen?
URE heißt nicht unbekannter Lesefehler sonder nicht mit der Fehlerkorrektur des Laufwerks korrigierbarer Fehler. - sowohl beim Lesen als auch beim Schreiben.
LTER hilft nur, damit das Betriebssystem nicht eine halbe Ewigkeit auf einen nicht mehr lesbaren Sektor wartet, bzw. im Falle von einem Hardware-Raidcontroller, damit dieser nicht meint das das Laufwerk komplett defekt ist, da es nicht mehr antwortet.

 

[dv2130n]

....Was ich aber nun gar nicht verstehe, ist, weshalb der gute Mann die URE-Wahrscheinlichkeit über die Brutto-Kapazität des Raid5 berechnet hat. Es wird doch nur die Netto-Kapazität gelesen, um die Parität wiederherzustellen. ......
Vielleicht hat sich auch schon mal jemand die Frage gestellt, aber was passiert eig. bzw. was hat es zur Folge, wenn so ein URE bei einer einzelnen Platte auftritt?

es wird erstens selbstverständlich über eine Brutto-Kapazität berechnet, und zweitens wird nicht nur eine Netto-Kapazität gelesen, sondern eine Brutto-Kapazität.
Sofern Brutto-Kapazität = Nutzdaten + Paritätsdaten, und Netto-Kapazität = Brutto-Kapazität - Pritätsdaten bedeuten soll.
Jetzt wird vielleicht klarer, warum mit einer Brutto-Kapazität gerechnet werden müss. Denn durch bloßes Lesen der Nutzdaten kann der Rebuild nicht durchgeführt werden.
Zur Durchführung des Rebuild ist es notwendig, dass erstens alle Nutzdaten gelesen werden (also sämtliche Nutzsektoren aller verbliebenen Festplatten nach dem Ausfall einer Platte) und
zweitens alle Paritätsdaten gelesen werden (sämtliche Paritätssektoren aller verbliebenen Festplatten. Denn die Paritätsdaten befinden sich ja nicht auf einer einzelnen Platte,
sondern werden genauso gestriped wie die Nutzdaten).
Wenn also das ursprüngliche raid-5 Array aus 10 Platten bestand und eine Platte fiel aus, dann werden beim Rebuild alle Sektoren (Nutzsektoren und Paritätssektoren)
aller verbliebenen 9 Festplatten während des Rebuild gelesen. Das ist klar eine Brutto-Kapazität (wenn auch nicht die ganze Brutto-Kapazität des unversehrten Array,
da ja eine Platte ausgefallen ist; man sollte auch eigentlich nicht von einer "Paritätsplatte" sprechen, die Paritätsplatte/n gibt es nämlich bei raid-5 und raid-6 nicht mehr,
sondern von "Paritätsdaten im Umfang einer oder zweier Platten", denn die Paritätsdaten werden wie die Nutzdaten über sämtliche Platten des Array gestriped.)

Demzufolge ist es so, dass durch einen Ausfall einer Platte nicht nur ein Teil der Nutzdaten verloren gehen, sondern auch ein Teil der Paritätsdaten.
Um zu verstehen, wie trotzdem die Daten der gesamten Platte rekonstruiert werden können, sollte man wissen, wie ein Rebuild funktioniert.

Eine Darstellung der Funktionsweise der Paritätsberechnung findet sich z.b. in RAID - Wikipedia, the free encyclopedia
In dem Beispiel wird die Kalkulation an einem Raid-5 bestehend aus 6 Disks einschliesslich einer sogenannten Hot Spare Disk gezeigt. Das Array besteht also aus Nutzdaten
im Umfang von 4 Platten, aus Paritätsdaten im Umfang einer Platte und aus der Hotspare-Disk. Die Situation ist, dass eine Disk ausfällt und der Rebuild wegen der eingelegten
Hot Spare Disk sofort beginnt.
Der Einfachheit halber wird in dem Beispiel angenommen, dass die Parity Informationen auf einer Disk, sozusagen der "Parity Disk" gespeichert werden. Tatsächlich liegen aber
natürlich auch die Parity Informationen gestriped, also verteilt auf alle Disks des Array (ausser der Hot Spare Disk) vor.
Zur Erläuterung des Xor sei, und das steht nicht in Wikipedia, folgendes gesagt:
Die Paritätsberechnung bedient sich des logischen Operators >entweder [a], oder < (am. >exclusive-or< oder kurz >xor<, lat."aut"), was in Langschrift bedeutet, daß eine mit diesem
Operator gebildete Proposition [c] insgesamt wahr ist, wenn der Vordersatz [a] wahr ist und der Nachsatz falsch ist oder umgekehrt, und falsch ist, wenn sowohl [a] als auch
wahr sind, oder wenn sowohl [a] als auch falsch sind. Oder kurz gesagt, eine xor-proposition ist wahr, wenn genau eines der Glieder wahr ist, sonst falsch.
Logisch gesehen ist der Operator xor überflüssig, denn er ist ersetzbar sowohl durch eine Kombination der Basis-Operatoren >Negation< und >Konjunktion<, als auch durch >Negation<
und >Alternation< (lat. "vel"). Sei >^< das Negationszeichen, >+< das Konjunktionszeichen und >-< das Alternationszeichen. >-< bezeichnet das nicht-ausschliessende Oder.
Dann ist >xor(a,b)< äquivalent mit (a+(^b))-((^a)+b), was wiederum sowohl äquivalent ist mit (^(a+b))+(^((^a)+(^b)) als auch mit (^((^a)-b))-(^(a-(^b))). Und natürlich folgt
aus den beiden Äquivalenzen, dass diese auch wiederum äquivalent zueinander sind. Das ist leicht einsehbar, denn die Beschreibung von Konjunktion und Alternation ist die gleiche,
bis auf vertauschte Rollen von Falschheit und Wahrheit. Aber das hier nur nebenbei.
Wikipedia nimmt nun weiter der Einfachheit halber an, dass jede Disk nur die Größe eines Byte (= 8 bit) hat. Disk-1 wird beschrieben mit der Bitfolge D1 := {00101010}, Disk-2 mit
D2 := {10001110}, Disk-3 mit D3 := {11110111}, Disk-4 mit D4 := {10110101}, als Hot Spare bleibt Disk-5 unbeschrieben und Disk-6 soll, gemäß obiger Einfachheitsannahme,
als "Parity-Disk" fungieren.
Das Wiki-Beispiel zeigt welches, Datum (welche Bitfolge) auf die "Parity-Disk" (also Disk 6) durch xor-Berechnung geschrieben werden muss. Da es sich um vier Nutzdaten-Disks handelt,
werden drei xor-Kalkulationen erforderlich. In welcher Reihenfolge oder Kombination die Kalkulationen durchgeführt werden, ist gleichgültig. Denn xor verhält sich assoziativ und
kommutativ (aber nicht idempotent).
Xor(D1,D2) ist äquivalent mit D1|2 = {10100100}. Xor(D1|2,D3) ist äquivalent mit D1|2|3 = {01010011}. Und xor(D1|2|3,D4) ist äquivalent mit D1|2|3|4 = {11100110}, was als Ergebnis
der Paritätsberechnung auf Disk-6 geschrieben wird.
Wenn nun Disk-3 ausfällt und ersetzt wird durch eine Hot Spare Disk, dann wird diese mit Informationen beschrieben, die rekonstruiert werden aus den Informationen aller
verbliebenen Nutzdaten-Disks und der "Parity-Disk". Wiederum ist eine kaskadierte xor-Kalkulation wie folgt erforderlich. Xor(D1,D2) ist äquivalent mit D1|2 = {10100100}.
Xor(D1|2,D4) ist äquivalent mit D1|2|4 = {00010001}. Und schliesslich ist xor(D1|2|4,D1|2|3|4) äquivalent mit D(1|2|3)|(1|2|3|4) = {11110111} = D3, womit also der
ursprüngliche Inhalt von Disk-3 wiederhergestellt wurde.

Wie erklärt es sich nun, dass es keine dedizierten "Paritätsdisks" in modernen raid-5 und raid-6 arrays mehr gibt, sondern die Paritätsdaten (wie die Nutzdaten) über alle
Disks des array gestriped werden, demzufolge bei einem Disk-Ausfall also auch Paritätsdaten verloren gehen, und sämtliche Daten der ausgefallenen Disk dennoch rekonstruiert
werden können?
Das erschließt sich klar aus dem oben bereits gesagten, und folgt genauer gesagt aus der logischen Äquivalenz von Nutzdaten und Paritätsdaten. Es können sowohl (wegen Plattenausfall)
fehlende Paritätsdaten wieder "vorgerechnet" werden, als auch (wegen Plattenausfall) fehlende Nutzdaten wieder "zurückgerechnet" werden. Paritätsdaten sind in keiner Weise
gegenüber den Nutzdaten ausgezeichnet oder umgekehrt. Diese Äquivalenz ist der Grund, weswegen natürlich auch die Paritätsdaten gestriped und im Fall des Fehlens
wegen Festplattenausfall eben wieder errechnet werden können, genauso wie die Nutzdaten.

Bei einem aus 10 Platten bestehenden raid-5 werden im Rebuild nach dem Ausfall einer Platte also alle Sektoren aller verbliebenen 9 Platten gelesen. Fehlt an einer Stelle ein
Paritätsdatum, dann wird es aus den Nutzdaten der 9 Platten errechnet, fehlt dagegen ein Nutzdatum, dann wird dieses fehlende Nutzdatum zurückgerechnet aus 8 Nutzdaten und
1 Paritätsdatum (wie oben vorgemacht) der (hier nun) 9 angenommenen Platten.

Die Wahrscheinlichkeit eines Lesefehlers während eines raid-5 rebuild erstreckt sich also selbstverständlich auf eine Bruttokapazität. Bestand das raid-array ursprünglich aus
n = 10 Platten von jeweils 1TB Kapazität, dann bezieht sich diese Lesefehlerwahrscheinlichkeit auf die n-1 = 9 verbliebenen Platten, also auf ganze 9TB.
Inwieweit eine solche Kapazität an die Lesefehlerrate der verwendeten Platten herankommt, das hatte ich bereits im "große raid-5 array"-thread vorgerechnet, will es aber
nochmal ausführlich darstellen, damit es auch wirklich jeder nachmachen kann:

die Chance für Datenverlust durch einen einzigen Sektor-Fehler im raid-5 array mit n Platten nach einem Plattenausfall liegt also bei
(n - 1) * Diskkapazität[in Bit] / Bit Error Rate [der verwendeten Platten]
raid-5 array aus 10 Platten á 1TB mit einer BER von 10^14,
dann tritt ein Lesefehler bei den verbliebenen 9 Platten mit folgender Wahrscheinlichkeit im Rebuild (nach dem Ausfall einer ersten Platte) ein:

1TB = 2^40 Bytes = 8 * 2^40 bits, da die Lesefehlerwahrscheinlichkeit nicht in Bytes, sondern in Bit angegeben wird und zwar nicht (wie bei Kapazitätsangaben von Festplatten
üblich) in Potenzen zur Basis 2, sondern in Potenzen zur Basis 10, muss hier also entsprechend umgerechnet werden. Und zwar wie folgt:
eine Potenz zur Basis 2 soll "ausgedrückt" werden in einer Potenz zur Basis 10. Wie mißt man ein Maß a mittels eines Maßes b? Nun, man teilt bekanntlich die Maßzahl a durch
die Maßzahl b und drückt dadurch a in b aus.
8 * 2^40 bits / 10^12 ergibt den Faktor 8,79; also sind 8 * 2^40 bits = 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 9 * 8,79 * 10^12 bits = 79,16*10^12 = 7,9*10^13 zu
lesenden Bits
beträgt nun die Lesefehlerrate der verwendeten 10^14 bits, dann ergibt sich 7,9*10^13 / 10^14 also 79% Chance, dass während des raid-5 rebuild durch Lesefehler der rebuild nicht
funktioniert und das array verloren geht.
Besteht die Speicherfläche von 7,9 * 10^13 bits aus Platten mit einer BER von 10^15 (nearline), dann beträgt diese Chance entsprechend nur 7,9%, und bei enterprise-grade disks mit
BER von 10^16 entsprechend nur 0,79%. Typische Consumer grade Platten sind also 10mal anfälliger für solche Fehler als nearline platten und 100mal anfälliger als enterprise grade platten.

und bezüglich Folgen von Lesefehlern auf Einzelplatten, das kommt auf die Art der Datei/en an, die es betrifft, manche Dateitypen sind toleranter gegenüber fehlenden Bits, andere nicht,
es macht z.b. durchaus nicht viel aus, wenn in einer Bilddatei einige bits fehlen; ausserdem wird es auf die Stelle der fehlenden bits ankommen, wie das datei-format mit mangelnder daten-integrität klarkommt; unter Umständen ist die betreffende Datei einfach nicht mehr lesbar

 

[Digi-Quick]

Beim Rebuild eines Raid 5 liegt aber nur noch die "Nettokapazität" vor, es kann also auch nur die Nettokapazität gelesen werden, da ja eine Platte im Verbund fehlt!

 

[andichen]

Die URE gilt nicht nur für Lese- sondern auch Schreibvorgänge.

Achso? Warum heißt "URE" dann "Unrecoverable Read Error"?

es wird erstens selbstverständlich über eine Brutto-Kapazität berechnet, und zweitens wird nicht nur eine Netto-Kapazität gelesen, sondern eine Brutto-Kapazität.
Sofern Brutto-Kapazität = Nutzdaten + Paritätsdaten, und Netto-Kapazität = Brutto-Kapazität - Pritätsdaten bedeuten soll.
Jetzt wird vielleicht klarer, warum mit einer Brutto-Kapazität gerechnet werden müss. Denn durch bloßes Lesen der Nutzdaten kann der Rebuild nicht durchgeführt werden.
Zur Durchführung des Rebuild ist es notwendig, dass erstens alle Nutzdaten gelesen werden (also sämtliche Nutzsektoren aller verbliebenen Festplatten nach dem Ausfall einer Platte) und
zweitens alle Paritätsdaten gelesen werden (sämtliche Paritätssektoren aller verbliebenen Festplatten. Denn die Paritätsdaten befinden sich ja nicht auf einer einzelnen Platte,
sondern werden genauso gestriped wie die Nutzdaten).

Ja, also Netto- und Brutto-Kapazität verstehe ich auch so bzw. habe ich das so gemeint. Warum muss aber die Brutto-Kapazität gelesen werden bzw. wie soll das gehen, wenn eine Platte ausgefallen ist und durch eine neue Platte ersetzt worden ist, die die Netto- wieder zur Bruttokapazität macht? Es bleiben ja nur die intakten Platten der Netto-Kapazität, auf deren Grundlage das Raid wieder in den "normalen Zustand" überführt werden kann. Die Parität kann doch auch nur durch das Lesen der verbleibenden (n-1)-Platten für ein Raid5 hergestellt werden. Auf die Ersatzplatte wird ja dann eigentlich auch nur geschrieben... Bei deiner Rechnung für die Wahrscheinlichkeit eines Sektorfehlers ziehst du ja auch eine Platte-(nkapazität) ab.

Also für mich bzw. rein logisch ist die Rechnung in der PDF noch falsch, habe leider noch keine konkreten Quellen dafür, dass es nicht so ist...

Edit: Freut mich, dass Digi-Quick das auch so sieht...

 

[dv2130n]

ich sage ja, dass EINE Brutto-Kapazität zur Errechnung der Wahrscheinlichkeit des Eintritts eines Lesefehlers beim Rebuild herangezogen werden muss,
natürlich nicht die ursprüngliche Brutto-Kapazität von 10 ganzen Platten, weil ja eine ganze Platte ausfiel
aber es muss die gesamte Kapazität aller restlichen 9 Platten zu dieser Berechnung herangezogen werden
und was befindet sich auf diesen verbleibenden 9 Platten?

Es befinden sich dort sowohl "Nutzdaten"-Sektoren/Streifen als auch "Paritätsdaten"-Sektoren/Streifen, und beide Arten von Sektoren müssen allesamt im vollen Umfang auf allen verbleibenden 9 Platten gelesen werden, um die durch den Ausfall einer Platte fehlenden Sektoren rekonstruieren zu können, wie in der Paritätsberechnung dargestellt.
Also handelt es sich bei dem, was beim Rebuild einzulesen ist, um eine Brutto-Kapazität (es müssen nämlich sowohl die verbliebenen Nutzdaten als auch die verbliebenen Paritätsdaten gelesen werden um überhaupt durch xor-berechnung die weggefallenen daten rekonstruieren zu können), es handelt sich demzufolge um eine verringerte Bruttokapazität, aber nicht um eine Nettokapazität. Denn nur anhand der Nettokapazität, also der Nutzdaten, könnten die Daten der ausgefallenen Platte nicht berechnet werden.
Und beim Verlust einer Platte gehen, wegen des Striping sowohl der Nutzdaten wie auch der Paritäts-Daten sowohl Nutzdaten wie auch Paritätsdaten verloren. Da beide Arten von Daten, wie in der xor-kalkulation aufgezeigt, logisch äquivalent sind, können auch beide rekonstruiert werden durch den Rebuild.
So schwer kann das doch nicht sein.

 

[pajaa]

Ein UWE (unrecoverable write error) macht keinen Sinn, da stimme ich andichen zu.

Ein RAID5 mit einer ausgefallenen Platte hat nur nur noch die Nutzkapazität (und nur in dem Fall machen die UREs überhaupt Probleme) und ein URE kann im schlimmsten Fall zum Fehlschlagen des Rebuilds führen. Damit ist das RAID aber immernoch betriebsbereit und die Daten können immernoch gesichert werden. Die Daten mit dem URE sind dann natürlich korrupt der ganz verloren.

 

[Digi-Quick]

Können wir uns auf folgende Definitionen in einem Raid 5/6 einigen
Bruttokapazität = Kapazität über alle Laufwerke des vollständigen Raids
Nettokapazit = Nutzkapazität (n-1) bzw (n-2)
Das ist mWn die allgemein gültige Definition!
Bei dir bzw. dem Vortrag wird eine Nettokapazität plötzlich zur Bruttokapazität....

Wenn in einem Raid 6 eine Platte ausfällt, braucht zur Wiederherstellung theoretisch auch nur die Nutzkapazität gelesen werden!
(ob das dann tatsächlich so ist denke ich macht wenig Sinn, da bei der Gelegenheit ja auch gleich die Konsitenz der Daten über die verbeleibenden Platten überprüft werden könnte)

 

[dv2130n]

Ein UWE (unrecoverable write error) macht keinen Sinn, da stimme ich andichen zu.

....

ein unrecoverable read error (ure) ist ein Fehler auf Hardware-Ebene, also Platten-Ebene, und bedeutet, dass die Platte den Fehler nicht mehr korrigieren kann,
nicht korrigierbar also auf die Platte bezogen, daher ist die BER zb. von 10^14 auch eine Plattenangabe und noch keine Raid-Array-Angabe
das bedeutet aber gerade nicht, dass dieser Fehler auch nicht mehr auf Raid-Array-Ebene korrigierbar ist

ein URE-Platten-Fehler kann gerade durch die Paritätsinformationen redundanter raids korrigiert werden
und zwar von einem intakten raid-5 und von einem intakten raid-6 ohnehin
bei einem raid-6 kann ein solcher Fehler aber auch nach Ausfall einer Platte, also beim Auftreten während eines Rebuild, korrigiert werden, und zwar wegen der zweiten Paritätsschicht von raid-6 arrays

 

[bluesunset]

Hrm, stimmt stimmt. Der Autor wie auch ich gingen vom normalen Verify aus nach einem Schreibvorgang. Entweder über die Laufwerkselektronik selbst oder mithilfe des Raidcontrollers.
Er hat es sich da einfacher gemacht indem er Allgemein von einer Unrecoverable Error Rate (UER) geredet hat.

• Seek Errors Less than 10 in 10^8 seeks
• Read Error Rates [1]
• Recovered Data Less than 10 errors in 10^12 bits transferred (OEM default settings)​
• Unrecovered Data Less than 1 sector in 10^15 bits transferred (OEM default settings)​
• Miscorrected Data Less than 1 sector in 10^21 bits transferred​

Aus Datenblatt für 10k6

Derjenige vom CERN hat neben der "parity" Disk sogar noch die ECC-Daten mit eingerechnet die auf den HDDs gespeichert sind. Da dies in der Berechnung von Whittington fehlt, nehme ich auch mal nicht die ganze Kapazität für eine Berechnung heran. Dies würde bei der älteren SCSI Platte nicht gerade wenig sein (aktuelle Laufwerke haben eher mehr):

Modell	LBAs in HEX bei 512byte/Sektor	Unformatiert
ST3146807	11177330h (146.8 GB)	189.6 GB
ST373307	88BB998h (73.4 GB)	94.8 GB
ST336607	445DCCCh (36.7 GB)	47.5 GB

 

[dv2130n]

Können wir uns auf folgende Definitionen in einem Raid 5/6 einigen
Bruttokapazität = Kapazität über alle Laufwerke des vollständigen Raids
Nettokapazit = Nutzkapazität (n-1) bzw (n-2)
Das ist mWn die allgemein gültige Definition!
Bei dir bzw. dem Vortrag wird eine Nettokapazität plötzlich zur Bruttokapazität....

Wenn in einem Raid 6 eine Platte ausfällt, braucht zur Wiederherstellung theoretisch auch nur die Nutzkapazität gelesen werden!
(ob das dann tatsächlich so ist denke ich macht wenig Sinn, da bei der Gelegenheit ja auch gleich die Konsitenz der Daten über die verbeleibenden Platten überprüft werden könnte)

hantiere doch bitte nicht mit "allgemeinen Definitionen" herum, wenn diese dir offenbar noch nicht so ganz klar sind,
nichts für ungut, aber dieser Eindruck ergibt sich zwingend
ein raid-5 aus 10 mal 1TB hat eine Brutto-Kapazität von 10TB und eine Netto-Kapazität von 9TB
da in raid-5 (und in raid-6) arrays sowohl die Nutzdaten als auch die Paritätsdaten gestriped, also über sämtliche Platten des Arrays verteilt werden, ergibt sich die Frage:
welche Brutto-Kapazität und welche Netto-Kapazität hat ein degradetes raid-5 array, also ein array bei dem 1 Platte ausfiel?
denn auf jeder der verbleibenden Platten befinden sich wegen des Striping sowohl Nutzdaten als auch Paritätsdaten
also stellen die verbleibenden ganzen 9 Platten zunächst einmal selbstverständlich eine Bruttokapazität dar, denn es befinden sich sowohl Nutz- als auch Paritätsdaten darauf

es werden zum Rebuild eines ursprünglich aus 10 Platten bestehenden raid-5 die gesamte Kapazität aller verbliebenen 9 Platten gelesen und da diese sowohl aus Nutzdaten als auch aus Paritätsdaten bestehen, handelt es sich logischerweise um eine Bruttokapazität
auch das kann nicht so schwer sein, oder?

 

[Digi-Quick]

Was mich auch ein wenig stört, ist daß die Ausfallwahrscheinlichkeiten der einzelnen Platten im Raid einfach addiert werden bzw. direkt hochgerechnet werden, ohne z.B. Gleichzeitigkeitsfaktoren einzubeziehen.

Die tatsächliche Ausfallwahrscheinlichkeit dürfte nämlich nur geringfügig über der einer einzelnen Platte liegen (sagen wir mal 6 % statt 4 %) und nicht wie in der Präsentation wunderschön vorgetragen 5x 4% = 20%.
Wobei wir uns darüber einig sein dürften, daß es Bereiche gibt wo selbst 6% zu viel ist!

Das ganze ist, wie schon von einem Vorposter angemerkt, eine sehr gut gemachte Verkaufspräsentation, die aber einer mathematisch korrekten interpretatioin nicht standhalten dürfte.
Nichts desto Trotz wird hier die Berechtigung von Enterprise-, insbesondere SAS Laufwerken eindrucksvoll dargestellt und unterstrichen.

Es steht ausserdem auch drin, daß man die Wahrscheinlichkeit eines UREs währen eines Rebulds auch dadurch reduzieren kann, daß man im vowege regelmässige Oberflächenscans durchführt (Background Media-Scan - dynamic certification) das hatte ich bereits in einem frühren Posting vermutet

 

[nobody27182]

Wahrscheinlichkeit für einen Bitfehler

...beträgt nun die Lesefehlerrate der verwendeten 10^14 bits, dann ergibt sich 7,9*10^13 / 10^14 also 79% Chance, dass während des raid-5 rebuild durch Lesefehler der rebuild nicht
funktioniert und das array verloren geht.

Diese Rechnung kann schon deshalb nicht stimmen, weil beim Lesen von 10[SUP]15[/SUP] Bits dann eine "Wahrscheinlichkeit" von 10 (1000%) für einen Lesefehler beim Rebuild bestehen würde. Bekanntlich liegen Wahrscheinlichkeiten aber per Definition zwischen 0 und 1.

Die Aussage über die Lesefehlerrate ist eine Aussage über den Erwartungswert einer Wahrscheinlichkeitsverteilung (hier: Exponentialverteilung). "Im Durchschnitt" wird ein nicht korrigierbarer Bitfehler per 10[SUP]14[/SUP] gelesenen Bits erwartet. Ein Bitfehler kann (in diesem einfachen Modell) auch nie auftreten, die WSK dafür strebt jedoch sehr schnell gegen 0.

Es gilt bei einer "10[SUP]14[/SUP] Platte" (Bits gelesen: WSK):

• 7,9 * 10[SUP]13[/SUP]: 0,546
• 10[SUP]14[/SUP]: 0,632
• 10[SUP]15[/SUP]: 0,99995

Bei einer "10[SUP]15[/SUP] Platte":

• 7,9 * 10[SUP]13[/SUP]: 0,076
• 10[SUP]14[/SUP]: 0,095
• 10[SUP]15[/SUP]: 0,632

 

[andichen]

Ach Leute, nun lasst doch den armen Ballon nicht platzen... Ich gebs ja zu, dass meine Unterscheidung nicht 100%ig korrekt war, habe das nur der besseren Geläufigkeit bzw. des praktischen Bezugs wegen so geschrieben. Mir und sicherlich allen anderen ist schon klar, dass auf jeder Platte eines Raid5 sowohl Nutz-, als auch Paritätsdaten liegen und dass bei einem Ausfall einer Platte nicht alle Paritätsdaten weg sind, sonden nur 1/n-tel davon. Die Gesamtmenge der Paritätsdaten, die beim Raid5 existiert, ist über alle Platten verteilt, sie entspricht der Kapazität einer am Raid5 beteiligten Festplatte. Für den Rebuildvorgang muss die verbleibende lesbare Datenmenge, bestehend aus Nutz- und Paritätsdaten, die praktisch gesehen auch der Nutzdatenmenge entspricht, gelesen werden. Hoffe, dass das jetzt deutlich und oft genug gesagt worden ist und wir wieder zur ursprünglichen Problematik zurückkehren können...

Ok, der Autor spricht vielleicht von der "UER", aber diese bezieht sich auch nur auf die gelesenen Bits. Er schreibt ja selbst: "The UER for SATA desktop products is 1 in 10[SUP]14[/SUP] bits read". Damit legt er sich schon fest...

Somit macht der Autor die Angelegenheit natürlich dramatischer als sie eigentlich schon ist... Vielleicht ist das auch nicht ganz unbeabsichtigt gewesen...