RAID6 Performance Problem

[UberJaeger]

Hallo,

ich habe schon seit einigen Jahren einen Adaptec 71605 Controller und auch eigentlich nie wirklich Probleme gehabt. Jetzt wollte ich mein RAID-System mal erweitern auf die maximale Anzahl von 16 (3TB Seagate Desktop) Platten, ich hatte bis vor kurzem noch 15 drin. Habe ein Backup gemacht auf ein anderes RAID und dann mit der neuen Platte ein komplett neues RAID aufgesetzt. Komischerweise hat das aufsetzen diesmal ca. 3 mal so lang gedauert wie sonst immer. Es hatte meist 6-8 Stunden gedauert, diesmal fast 20. Was aber noch viel gravierender ist, der Speed. Und zwar hatte ich sonst immer lesend 700-900 MB/s und schreibend auch so um die 600-700 MB/s. Jetzt habe ich lesend 200 mb und schreibend 20 !!! MB/s. Woran kann das liegen ?

Alle Platten sind das gleiche Modell von Seagate (ST3000DM001), aber natürlich im Laufe der Jahre gab es immer neue Revisionen. Das war aber noch nie ein Problem. Jetzt vermute ich das ich irgendwas beim aufsetzen falsch eingestellt habe, den Cache glaub ich. Ich denke write-back war das richtige, habe aber aus versehen cache deaktiviert bei den optionen. Das erklärt aber trotzdem nicht die extrem schlechte Performance vor allem beim schreiben. Also da ist ja eine einzelne Platte schneller. Von daher vermute ich entweder einen Defekt beim Controller oder kann es auch sein das eine defekte Festplatte den Speed so herunterzieht ? Ich bin gerade etwas ratlos.

MfG

 

[Eye-Q]

Naja, ohne Caching wird direkt auf die Festplatten geschrieben, und da bei einem RAID6 zwei Paritäten berechnet werden müssen, und das über 16 Platten, hat die XOR-Einheit des Controllers schon sehr ordentlich zu tun. Da der Controllerchip auch schon über 5 Jahre alt ist, ist der nun mal nicht mehr der schnellste.

Was passiert denn, wenn Du den Cache wieder einschaltest? Das beeinflusst das RAID selbst ja nicht, nur die Art und Weise wie der Controller mit den Daten umgeht, also ob der erstmal in den Cache oder direkt auf die Platten schreibt.

 

[UberJaeger]

Hat sich leider nichts geändert, ich habe beim Controller die Config mal zurückgesetzt, was ich nicht wusste ist das das Logische Volume dann auch wieder gelöscht wird. Jetzt setze ich das RAID nochmal mit Write-Back auf und werde morgen nochmal hier schreiben wenn es fertig ist.

 

[Holt]

maximale Anzahl von 16 (3TB Seagate Desktop) Platten, ich hatte bis vor kurzem noch 15 drin.
...
Alle Platten sind das gleiche Modell von Seagate (ST3000DM001)

Diese HDDs sind für diesen Einsatz nicht geeignet, es sind einfache Desktopplatten ohne TLER/ERC, die sind für 2400 Betriebsstunden, 55TB Workload im Jahr und den Einsatz als einzige HDD im Gehäuse gemacht. Für 16 muss man die Enterprise NAS, Red Pro, HGST Deskstar NAS oder Enterprise Nearline HDDs nehmen, selbst die einfache Seagate NAS/Ironwolf/SkyHawk oder WD Red sind nur für bis zu 8 HDDs in einem Gehäuse zugelassen.

Über jegliche Art von Probleme sollte man sich also nicht wundern, wenn man Platten verwendet die für diese Nutzung nicht geeignet sind und auch Performanceprobleme könne von Vibrationen kommen, siehe "Shouting in the Datacenter"!

 

[UberJaeger]

Ja ich weiss das die Platten dafür nicht geeignet sind und das war auch der größte Fehlkauf damals, aber der Preis für einen Umstieg ist eben enorm. Die Performance war auf jeden fall sehr gut die ganzen Jahre, nur jetzt will es auf einmal nicht mehr.

 

[Holt]

Dann schau Dir mal die S.M.A.R.T. Werte an, wenn die schon jahrelang so betrieben wurden, dann dürften die Platten einfach fertig sein, denn die machen so grob nach 20.000 Betriebsstunden schlapp. Bei den vorgesehenen bis zu 2400 Power On Hours im Jahr würde es aber auch über 7 Jahre dauern bis sie die erreicht haben. Um einen Neukauf wirst Du daher kaum herum kommen und dann solltest Du passende HDDs nehmen, denn auch wenn man es ihnen von außen nicht ansieht, intern unterscheiden sich die einzelnen Serien teils deutlich und die billigen Desktopplatten sind eben darauf optimiert billig zu sein, auch wenn das zur Folge hat das sie eben nicht für jeden Einsatzzweck taugen, aber dafür gibt es ja andere Serien die dann weniger stark kostenoptimiert sind und für so einen Einsatz taugen, aber eben mehr kosten.

Also Ersatz würde ich die SkyHawk oder Ironwolf mit 6TB oder 8TB nehmen, die haben eine UBER von 1:10^15, die kleineren der Serien haben ebenso wie auch die WD Red, Red Pro und HGST Deskstar NAS nur 1:10^14, und sind für bis zu 8 HDDs in einem Gehäuse zugelassen (Enterprise NAS, Ironwolf Pro, Red Pro bis 16, HGST Deskstar NAS meines Wissens nach unbeschränkt) und kosten pro TB auch nicht mehr als die kleinen 4TB der gleichen Serien. Damit wäre selbst ein RAID 5 mit 8 x 8TB zu verantworten, denn bei einer UBER von 1:10^15 hat man dann immer noch eine theoretische Chance von fast 62% auf ein erfolgreiches Rebuild, und da RAIDs keine Backups ersetzen, sollten entweder die Daten nicht so wichtig sein oder es ein Backup davon geben.

 

[NixName]

Was benötige ich für eine theoretische Chance 100% Rebuild 5 Platten a 4TB?

 

[UberJaeger]

62% hört sich irgendwie nicht gut an für ein Rebuild. Warum ist der Wert so niedrig ? Mit Rebuild meinst du wenn eine Platte mal aussteigt, die Zeit bis es braucht um mit einer neuen Platte wieder einen optimalen RAID-status zu bekommen ?

Einige Platten aus dem RAID musste ich die letzten 2 Jahre schon tauschen weil sie ausgestiegen sind. So an die 7 Stück müssten das mittlerweile sein, von daher will ich ja auch weg von den Platten. Ich denke mal das du recht hast und ich komme wohl nicht um ein größeres Investment herum. Und ja die Daten werden gesichert, aber leider sehr selten, da ich das bei nem Kumpel sichere. Das meiste ist nicht wichtig, aber ein paar Sachen schon, die habe ich aber dann auch nochmal extra gesichert. Deswegen hatte ich ja auch nicht so teure Platten gekauft weil es einfach nur ein Datengrab ist. Aber ich merke das man damit im Endeffekt durch die ganzen Ausfälle auch nicht billiger davon kommt, eher noch teurer.

 

[Holt]

Was benötige ich für eine theoretische Chance 100% Rebuild 5 Platten a 4TB?

100% gibt es nicht, selbst bei einem RAID 6 wo man dem nahe kommt, solange nur eine HDD ausgefallen ist. Dann funktioniert es immer noch als RAID5 und damit müssten nicht nur 2 HDDs beim Rebuild einen Lesefehler haben, sondern diesen auch noch an der gleichen Adresse bekomme. Da kann man dann über die AFR und die Dauer des Rebuild eher die Wahrscheinlichkeit ausrechen das zwei Platten wären des Vorgangs komplett ausfallen.

62% hört sich irgendwie nicht gut an für ein Rebuild. Warum ist der Wert so niedrig ?
Mit Rebuild meinst du wenn eine Platte mal aussteigt, die Zeit bis es braucht um mit einer neuen Platte wieder einen optimalen RAID-status zu bekommen ?

Wieso niedrig, mehr als eine UBER von 1:10^15 gibt es bei 3.5" HDDs nicht und bei einer 1:10^15 muss man im Prinzip alle etwa 120TB gelesener Daten mit einem Lesefehler rechnen, was bei einem Rebuild eines RAID 5 dann in aller Regel zu einem Abbruch führt. Wenn also 8 TB gelesen werden müssen und alle 120TB auf Fehler auftreten kann, es muss nicht passieren die Fehler treten ja nicht garantiert mit der Häufigkeit auf, so sind die Wahrscheinlichkeit das dies klappt eben 0,933. Besteht das RAID 5 aus 8 HDDs und es ist ein Rebuild fällt, müssen die 7 verblieben alle fehlerfrei gelesen werden können, dafür ist die Wahrscheinlichkeit also 0,933^7 = 0,617.

Das ist wie gesagt ein theoretischer Wert, die Hersteller geben mit der UBER an wie oft mit einem Lesefehler gerechnet werden muss, ohne dass die HDD deswegen ihre Spezifikationen verletzten würde. Der Wert gilt natürlich nur, wenn man die HDD auch innerhalb ihrer Spezifikationen betreibt, was bei den derzeit verbauten ST3000DM001 schon mal wegen der Anzahl der Platten in einem Gehäuse und vermutlich der Betriebsstunden pro Jahr nicht der Fall ist.

Einige Platten aus dem RAID musste ich die letzten 2 Jahre schon tauschen weil sie ausgestiegen sind.

Das ist Desktopplatten ohne TLER/ERC an einem HW-RAID Controller auch kein Wunder. SATA Festplatten versuchen bei problematischen Sektoren diese doch noch erfolgreich zu lesen und die Desktopplatten geben dies versuchen meist erst nach so 14s auf. Diese Zeit kann man bei ihnen auch nicht einstellen, wenn man die einstellen kann, dann spricht man davon das die HDD TLER (Time Limited Error Recovery) hat, wobei genau das jede HDD hat. Seagate nennt es ERC (Error Recovery Control) was die Sache besser beschreibt, denn ist nur die Kontrolle über die Zeit wie lange die HDD selbst versucht den Fehler doch noch zu korrigieren.

Bei HDDs die TLER bzw. ERC haben, ist der Timeout der HDD dann nicht nur einstellbar, sondern auch meist ab Werk schon kürzer voreingestellt, in aller Regel auf 7s, weil nämlich HW RAID Controller ab Werk meist auf einen Timeout von 8s eingestellt sind, so lange warten sie auf eine Antwort der Platte und wenn in der Zeit keine Antwort kommt, also weder die Daten noch ein Lesefehler, fliegt die Platte als defekt aus dem RAID. Hat die Platte es aber nach dem Timeout des Controller und vor ihren eigenen doch noch geschafft die Daten zu lesen, findet sich hinterher nicht einmal ein schwebender Sektor in den S.M.A.R.T. Werten und der Laie wundert sich erst recht warum die Platte aus dem RAID geflogen ist, denn wenn Sektoren nicht mehr gelesen werden können, markiert der Controller der Platte diese als schwebende Sektoren.

Den Lesefehler merkt man in einem echten RAID erstmal aber nicht, RAID 0 sind keine echten RAID weil die Redundanz fehlt für die das R in RAID steht, denn der Controller rekonstruiert die Daten aufgrund der Daten der anderen Platten zu denen auch die Parity gehört. Wäre nun aber eine RAID taugliche HDD mit TLER/ERC genommen worden, hätte diese den Lesefehler auch rechtzeitig gemeldet und wäre damit nicht aus dem RAID geflogen, der Controller hätte den Sektor obendrein noch mit den rekonstruierten Daten überschrieben und daraufhin würde der Controller der Platte prüfen ob diese "neuen" Date nun korrekt gelesen werden können und der schwebende Sektor würde sofort wieder verschwinden, ggf. würde der Sektor durch einen Reservesektor ersetzt werden. Das RAID wäre weiterhin vollständig intakt.

Daher sind Desktopplatten an HW RAID Controller das total NoGo!

So an die 7 Stück müssten das mittlerweile sein, von daher will ich ja auch weg von den Platten.

Wenn die schon 2 Jahre in Betrieb sind, dürfte die Ausfallrate noch weiter massiv ansteigen, viel länger halten die ST3000DM001 so einen Betrieb nicht durch.

Ich denke mal das du recht hast und ich komme wohl nicht um ein größeres Investment herum.

Wenn Du schon 7 von 16 getauscht hat und diese nicht über Gewährleistung oder Garantie kostenlos ersetzt wurden, was das inzwischen ein teurer Spaß und billigsten Platten (die ST3000DM001 waren lange die billigsten 3TB HDD und auch sonst in €/TB wirklich ganz weit vorne beim Preis) zu nehmen ist am Ende schon richtig teuer geworden. Das war aber leider so vorhersehbar und wenn Dich da jemand beraten hat es so zu konfigurieren, war das eine klar Fehlberatung.

Deswegen hatte ich ja auch nicht so teure Platten gekauft weil es einfach nur ein Datengrab ist. Aber ich merke das man damit im Endeffekt durch die ganzen Ausfälle auch nicht billiger davon kommt, eher noch teurer.

Eben, billig wird dann teuer und wenn man Profi HW wie so einen RAID Controller mit Consumer HW wie diesen billigen Desktopplatten mischt, dann muss man aufpassen, irgendwie geht das zwar alles, aber da gibt es eben einige Fallstricke. Richtige RAIDs mit SAS Platten arbeiten nämlich noch mal anderes, da gibt es auch kein Problem mit der TLER / ERC, die nur ein Notbehelf ist. Die passenden SAS HDDs für solche RAID Controller können nämlich auf andere Sektorgrößen wie 520/524/528 Bytes pro Sektor umformatiert werden, was bei SATA Platten nicht geht. Der Controller legen in den zusätzlichen Bytes eine eigene Prüfsumme ab und steuert die Platten so an, dass sie ihm auch dann die ganzen Daten geben, wenn diese nicht korrekt sind, was SATA Platten so auch nicht machen. Damit kann der RAID Controller dann aber auch sofort selbst erkennen ob die Daten stimmen und muss nicht warten ob die HDDs diese vielleicht doch noch korrekt liest oder bis sie den Versuch aufgibt, sondern kann eben sofort die Daten aufgrund der Daten der anderen Platten korrigieren und überschreiben, was eben Verzögerungen vermeidet die bei viele Produktivsystemen wie z.B. bei Datenbanken nicht akzeptabel wären.

 

[mika2004]

ich kenne so etwas von LSI-Controllern.
Dort gibt es einen Schalter mit dem Namen Disk-Cache.
Ist dieser nicht enabled, tritt genau eine solche schlechte Performance auf.
Diesen kann man auch noch nachträglich verändern.

Vielleicht gibt es bei Dir ja was vergleichbares.

 

[UberJaeger]

Danke für die ausführlichen Erklärungen @Holt.

Würdest du eher 8x8 Ironwolf im Raid5 oder 6x10 Ironwolf im Raid5 empfehlen ? Bei letzterem sind ja nochmal 2 Platten weniger und somit auch weniger Fehlerquellen, vom Preis her ist es fast identisch. Oder gleichen sich die Fehlerquellen mehr oder weniger wieder aus weil ja wohl in den 10TB Platten eine Scheibe mehr drin rotiert ?

 

[fdsonne]

Würdest du eher 8x8 Ironwolf im Raid5 oder 6x10 Ironwolf im Raid5 empfehlen ? Bei letzterem sind ja nochmal 2 Platten weniger und somit auch weniger Fehlerquellen, vom Preis her ist es fast identisch. Oder gleichen sich die Fehlerquellen mehr oder weniger wieder aus weil ja wohl in den 10TB Platten eine Scheibe mehr drin rotiert ?

Die Frage ist eher, wie viel Platz muss am Ende rauskommen??
Ich würde KEIN Raid5 empfehlen... Die Aussagen von Holt oben sind definitiv vorsichtig zu genießen. Es ist einfach unsinnig, einerseits auf den Spezifikationen der HDDs rumzupochen und dann andererseits exakt das Selbe dort zu tun, was man eigentlich nicht macht. Nämlich das Raid5 mit 8x HDDs Eigentlich ist das Raid5 vollständig, nunja, eher ungünstig um es mal durch die Blume auszudrücken. Du sparst sozusagen am völlig falschen Ende! Und für den Invest, so eine 8TB Ironwolf Disk kostet mal schlappe 275€ inkl. MwSt., macht 2200€ in Summe. Und dann noch so eine unsinnige Konfig?

Es gibt ja eben nicht nur diese besagten Lesefehler im "Schnitt" auf die Datenmenge, sondern noch andere technische Probleme, die dir da in die Suppe spucken könnten. Auch das Argument "Backup" ist gut und schön, aber nicht Sinn der Sache. Wenn du dich zwangsweise auf das Backup verlassen sollst, dann kannst du dir das Raid gleich schenken und damit auf den Platz der Parity Daten verzichten, denn im Zweifel ist es genau das, was hinten bei rum kommt. Nämlich ein Raid5, was den Rebuild nicht überlebt...



Konkret zur Frage:
- 8x8TB macht ca. 51TB real nutzbarer Platz im Raid5
- 6x10TB macht ca. 45TB real nutzbarer Platz im Raid5
- 8x8TB macht ca. 43TB real nutzbarer Platz im Raid6!

Du kommst mit 16x3TB Disks im Raid6 ja auf ca. 38TB real nutzbar.
Wenn du also auf die letzten paar TB verzichten kannst -> dann mach ein Raid6 über 8x8TB, kommt auf knapp die gleiche Größe wie das 10TB Raid5 mit 6x Disks und du hast alle Vorzüge durch die zweite Parität bei dem potentiellen Nachteil, eben die volle Anzahl zugelassener Disks im System zu haben.


PS: diese Angabe finde ich persönlich auch eher wie schall und rauch... Nur so als Randinfo. Denn es gibt nicht nur Disks, die im PC "vibrieren". Die Frage ist, was ist die Basis?
So eine 140x140 Lüfterwand mit vollen Touren, entsprechend Laut und mit viel Durchsatz bspw. lässt das Case defakto mehr wackeln wie 1-2 Hände voll Disks... Oder ein MGPU System bei 100% Lüfterspeed auf dem Radiallüftern...
Oder wenn die Kiste direkt neben nem fetten Soundsystem steht usw. usf.


Übrigens nochmal kurz zur Eingangsfrage, hast du denn mal den Gegentest gemacht, den Cache auf dem Array wieder zu aktivieren? Weil normal ist das einfach nur ein Schalter, den man dort umlegt. Von Write Back zu Write Through und umgekehrt. Die Controller selbst switchen die Modi oftmals auch in Phasen, während bspw. eine angeschlossene BBU lädt oder in der Kalibrierung ist oder bei so manchem Wartungstasks...
Ebenso wäre natürlich der Quertest einfach mal zu tätigen, ob es mit 15 Disks wieder "schnell" geht oder nicht... Es könnte ja auch das Kabel, die neue Disks, der Port am Controller oder sonstwas da für Probleme sorgen. Oder die Initialisierung war einfach noch nicht durch -> und ohne Write Back kommt einfach kein Speed auf die Disks...

 

[UberJaeger]

Heute habe ich ein wenig rumexperimentiert und auch ein identischer Controller als Tausch stand zur Verfügung. Mit diesem war leider auch das Performance-Problem, somit ist der Controller als Fehler ausgeschlossen. Write-Back in den Einstellungen hatte auch keine Änderung zur Folge. Ich habe mal als Spielerei ein RAID 0 erstellt mit allen 16 Platten, da war der Speed extrem schnell, wie kann man sich das erklären ? Kommen die Platten dann irgendwie nicht klar wegen der Parität ? Aber warum ging es mit 15 noch gut und mit 16 nicht mehr. Zur Info, ich habe anhand der SMART-Werte auch 2 alte Platten noch raus genommen und nicht nur eine neue, sondern 3 neue ins RAID wieder eingebaut um auf die 16 zu kommen, aber auch das hat ja nicht geholfen. Ich hab jetzt ehrlich gesagt keine Lust nochmal mit weniger Platten ein RAID6 zu erstellen weil im Endeffekt falls es dann wieder schnell geht, habe ich auch nix gewonnen ausser die Erkenntnis das es eben irgendwie mit der Anzahl der Platten oder einer/mehrerer bestimmter Platten zu tun hat, vielleicht ja auch wegen den neuen weil die auch mal wieder eine neue PN-Nummer haben, ich glaube es gibt bei der Modellserie bestimmt mehr als 5 verschiedene Revisionen und ich hab bestimmt einige unterschiedliche davon in dem RAID.

 

[Digi-Quick]

wie sind den die Cache Enstellungen der einzelnen HDDs?

 

[Holt]

Würdest du eher 8x8 Ironwolf im Raid5 oder 6x10 Ironwolf im Raid5 empfehlen ?

Die theoretische Chance auf ein erfolgreiches Rebuild wäre bei einem RAID 5 aus 6 x 10TB 64,7%, also nur wenig besser als bei 8 x 8 TB mit jeweils eines UBER von 1:10^15. Der Vorteil der 10TB HDDs von Seagate ist, das diese eben mit Helium gefüllt sind und daher eine geringere Leistungsaufnahme haben. Bei nur 6 statt 8 HDDs spart man obendrein nicht nur wegen der Art und geringeren Strom, sondern auch SATA Ports und Einbauplätze, wobei beides in diesem Fall wohl sowieso vorhanden ist.

Oder gleichen sich die Fehlerquellen mehr oder weniger wieder aus weil ja wohl in den 10TB Platten eine Scheibe mehr drin rotiert ?

Wieso wollten mehr Platter eine so viel größere Fehleranfälligkeit bedeuten? Die Köpfe fallen meist nur wegen äußerer Einflüsse wie Stößen aus, HDDs sind eben empfindlich wie dieses Video von HGST über die Empfindlichkeit und korrekt Handhabung von HDDs zeigt. Ob die 10TB nur ausfallfreudiger als die 8TB sind, wird erst die Zukunft zeigen, es gibt immer mal Modelle oder Serien die mehr und andere die weniger Probleme haben. Generell sehe ich aber keine Zusammenhang zwischen den Ausfallraten und der Kapazität. Bei der WD Red scheint es wirklich so zu sein, dass die größeren Kapazitäten mehr Ausfälle haben:

0,81% WD Red WD20EFRX
0,96% Western Red WD30EFRX
2,02% WD Red WD40EFRX
3,37% WD Red WD60EFRX

Aber die Seagate NAS zeigt dieses Verhalten nicht, da fällt aber der 3TB die Ausfallraten ab:

0,56% Seagate NAS HDD ST2000VN000
1,41% Seagate NAS HDD ST3000VN000
1,04% Seagate NAS HDD ST4000VN000
0,00% Seagate NAS HDD ST6000VN0021

Generell liegen die Seagate bei den 5 und 6TB HDDs vorne:

5 / 6 To :

3,42% Toshiba Toshiba X300 5 To
3,37% WD Red WD60EFRX
2,67% WD Green WD60EZRX
1,43% WD Red WD50EFRX
0,87% Seagate Enterprise NAS HDD ST6000VN0001
0,74% Seagate Desktop HDD ST6000DM001
0,00% Seagate NAS HDD ST6000VN0021

Die Archive scheint hingegen das schwarze Schaf der Seagate HDD Familie zu sein, aber für HW RAIDs ist die wegen SMR überhaupt nicht geeignet.

Ich würde KEIN Raid5 empfehlen... Die Aussagen von Holt oben sind definitiv vorsichtig zu genießen.

Nein, Deine Aussagen sind generell mit Vorsicht zu genießen, aber als Mod kannst Du es Dir erlauben, man kann Dich nicht ignorieren und wenn man Deine Aussagen kritisiert, bist Du in Deiner Machtposition als Moderator Dir auch nicht zu schade diese auszunutzen. Daber würde es gerade einem Moderator gut anstehen sich zurückzuhalten, wenn er keine Ahnung vom Thema hat, aber das sieht man bei Dir leider nicht.

Es ist einfach unsinnig, einerseits auf den Spezifikationen der HDDs rumzupochen und dann andererseits exakt das Selbe dort zu tun, was man eigentlich nicht macht. Nämlich das Raid5 mit 8x HDDs

Und warum? Die Aussage ist pauschal ohne auf die UBER der HDDs einzugehen einfach totaler Blödsinn, denn natürlich macht es eben einen gewaltigen Unterschied ob die HDDs eine UBER von 1:10^15 oder nur von 1:10^14 haben, denn mit 1:10^14 wäre die theoretische Chance auf ein Rebuild eines RAID5 auf 8 x 8TB nur noch weit unter einem Promille. Bei einer UBER von 1:10^15 sieht es aber ganz anderes aus und ich kenne RAID 5 mit über 30 Enterprise 15krpm HDDs a 600GB mit einer UBER von 1:10^16 die inzwischen schon mehrere Rebuild erfolgreich hinter sich gebracht haben, aber da liegt die Chance auch bei so vielen HDDs noch bei über 85%!

Eigentlich ist das Raid5 vollständig, nunja, eher ungünstig um es mal durch die Blume auszudrücken.

Nein nicht durch die Blume, sondern um ohne eigenes Wissen das Gelaber der anderen wiederzugeben die auch nicht mehr wissen. Klar sind 62% bei RAID 5 oder fast 100% beim RAID 6 ein Unterschied, aber man muss eben auch eine HDD mehr kaufen ohne mehr Nutzkapazität zu erhalten und bekommt in aller Regel weniger Performance.

Es gibt ja eben nicht nur diese besagten Lesefehler im "Schnitt" auf die Datenmenge, sondern noch andere technische Probleme, die dir da in die Suppe spucken könnten.

Und welche bitte? Wenn man schon klugscheißt, sollte man auch klug sien Moderator hin oder her!

Auch das Argument "Backup" ist gut und schön, aber nicht Sinn der Sache. Wenn du dich zwangsweise auf das Backup verlassen sollst, dann kannst du dir das Raid gleich schenken

Ein RAID schützt nur bei Lesefehlern einer HDD, die aber eben regelmäßig zu erwarten sind und bei Ausfall eines HDD, aber nicht gegen versehentliches Löschen, Verschlüsselungsviren, einen Sturz des Gehäuses mit den HDDs darin oder auch z.B. einem Abgang des Netzteils bei dem es die HDDs mitnimmt. Alles schon da gewesen, von Bränden oder Diebstahl will ich nicht anfangen. Wer meint ein RAID würde ein Backup ersetzen, der sollte sich wirklich Gedanken darüber machen ob HDD Ausfälle wirklich die einzigen relevanten Risiken für seine Daten sind.

und damit auf den Platz der Parity Daten verzichten

Weil Lesefehler immer wieder vorkommen, sollten man genau nicht auf die Parity verzichten, schon gar nicht wenn man kein Backup hat, da sonst jede betroffene Daten korrupt wäre und wenn wichtige Metafaten des Filesystems betroffen wären, noch viel mehr.

, denn im Zweifel ist es genau das, was hinten bei rum kommt. Nämlich ein Raid5, was den Rebuild nicht überlebt...

Das ein RAID einen Rebuild überlebt, kann man nie garantieren, auch nicht bei einem RAID 6, womit wir wieder beim Thema Backup wären.

Konkret zur Frage:
- 8x8TB macht ca. 51TB real nutzbarer Platz im Raid5

Nein, den Unterschied zwischen TB und TiB sollte man schon kennen, auch wenn Windows diese nicht zu kennen scheint. 8x8TB in einem RAID5 erben 7x8TB = 56TB = 50,9TiB Nutzkapazität. Außerdem können HW RAID Controller RAIDs auch um neuen HDDs erweitern, die danach gleichberechtigte Member des RAIDs sind, was z.B. ZFS nicht kann. Es reicht also die anfangs erforderliche Kapazität anzuschaffen, dann kann man immer noch anbauen.

diese Angabe finde ich persönlich auch eher wie schall und rauch... Nur so als Randinfo. Denn es gibt nicht nur Disks, die im PC "vibrieren".

Es kommt auch auf die Frequenz der Vibrationen an, von HDDs mit etwa der gleichen Drehzahl ist eben kritischer als die von einem Lüfter.

Oder wenn die Kiste direkt neben nem fetten Soundsystem steht usw. usf.

Da gehört sie sowieso nicht hin, siehe "Shouting in the Datacenter", dies ist also sowieso dringend zu vermeiden und Bässen haben schon einigen Probleme mit ihren HDDs bereitet.

 

[fdsonne]

Nein, Deine Aussagen sind generell mit Vorsicht zu genießen, aber als Mod kannst Du es Dir erlauben, man kann Dich nicht ignorieren und wenn man Deine Aussagen kritisiert, bist Du in Deiner Machtposition als Moderator Dir auch nicht zu schade diese auszunutzen.

Echt? Ist das so??? Du bist unfehlbar? Ich glaube nicht... Gern darfst du mir Belege zu diesen Unterstellungen in mein Postfach übersenden... Andernfalls ist das einfach nur haltloses Getrolle. Sorry, aber damit machst du dich lächerlich
Für dich zur Erklärung, deine UBER Rechnung ist schlicht und einfach reinste Theorie. Warum? Es geht nicht bei Null los. Das Array arbeitet ja schließlich. Sprich der TE wird dort, bei diesen Datenmenge, die ja offenbar auch ansatzweise belegt werden, gewisse Transferleistungen erzielen.
Es kommt also eins zum anderen. Ein HDD Totalausfall (wie du sicher weist, ist was völlig anderes als ein "simpler" Lesefehler) gepaart mit einem Lesefehler würde ein Raid5 in dieser Konstellation für den Hintern machen... Das wäre so ziemlich das worst case Szenario. Für solche Szenarien nutzt man bspw. doppelte Parität.
Dir als Person, die angeblich Ahnung hat -> obwohl ich das bei der mangelnden Sachlichkeit eher bezweifeln würde, sollte wohl bekannt sein, dass HDDs nicht ausschließlich wegen Lesefehlern nach einer Warscheinlichkeit des UBER Wertes "ausfallen".

Aber schön wie du genau das bestätigst, was ich oben sagte. Du versteifst dich die UBER Rechnung, blendest alle potentiellen Baustellen aus und drückst deine Raid5 Empfehlung durch ohne mal nach links oder rechts zu blicken. DAS ist nicht seriös (meine Meinung)

Nochmal für dich zum mitschreiben, es geht mir darum, du pochst auf den Spezifikationen der Disks (und bist damit hier im Forum einer der wenigen, die es derart genau nehmen) und im nächsten Step paarst du diese löbliche rangehensweise ausschließlich mit theoretischen best case Überlegungen -> wie passt das zusammen? Wenn du davon ausgehst, dass die Disks mit dem Betrieb außerhalb der Spezifikationen NICHT überleben werden -> wieso empfiehlst du dann im selben Atemzug ein anderes Szenario, was genau auf Kante genäht ist? Das ist Unsinn und keine seriöse Empfehlung. Denn der UBER Wert ist eben NICHT alles. Das solltest du eigentlich wissen, zumindest deinem "Sprech" her scheinst du der Meinung zu sein, dich in der Materie auszukennen
Weder gibt es hier ein Budget -> wer sagt, das der TE, wenn er 2200€ für 8x8TB Disks ausgibt, nicht auch bereit wäre, bspw. 2600€ für 7x10TB Disks auszugeben und dann ein Raid6 mit allen Vorzügen zu fahren?
Noch gibt es hier eine Vorgabe zum benötigten Platz... Vielleicht reichen ihm ja sogar die 8x8TB im Raid6...

Die Aussage ist pauschal ohne auf die UBER der HDDs einzugehen einfach totaler Blödsinn, denn natürlich macht es eben einen gewaltigen Unterschied ob die HDDs eine UBER von 1:10^15 oder nur von 1:10^14 haben, denn mit 1:10^14 wäre die theoretische Chance auf ein Rebuild eines RAID5 auf 8 x 8TB nur noch weit unter einem Promille.

Hat ja auch nirgends wer angezweifelt... Es geht immernoch darum, dass der UBER Wert nicht alles ist. Nicht mehr und nicht weniger... Wenn du anderer Meinung bist, stell dich wenigstens der Kritik

Ich sagte nic Bei einer UBER von 1:10^15 sieht es aber ganz anderes aus und ich kenne RAID 5 mit über 30 Enterprise 15krpm HDDs a 600GB mit einer UBER von 1:10^16 die inzwischen schon mehrere Rebuild erfolgreich hinter sich gebracht haben, aber da liegt die Chance auch bei so vielen HDDs noch bei über 85%! Nein nicht durch die Blume, sondern um ohne eigenes Wissen das Gelaber der anderen wiederzugeben die auch nicht mehr wissen. Klar sind 62% bei RAID 5 oder fast 100% beim RAID 6 ein Unterschied, aber man muss eben auch eine HDD mehr kaufen ohne mehr Nutzkapazität zu erhalten und bekommt in aller Regel weniger Performance.

Jetzt kommen wir der Sache schon näher
Wenn du nun noch die Überheblichkeit ablegst, könnte man vielleicht über genau diesen Umstand sprechen. Denn mir stellt sich die Frage, wieso versuchst du dem TE hier die offenbar deutlich! schlechtere Raid5 Lösung ans Bein zu binden. Er fährt JETZT ein Raid6. Zugegeben, außerhalb der Disk Spezifikationen. Aber selbst diese Konstellation hat nach reiner Theorierechnung weniger Warscheinlichkeit als deine Raid5 Empfehlung... Genau darum gehts und nichts anderes. Wenn du schon so viel Ahnung hast, wie du behauptest, wäre wenigstens die Wahl mit der Benennung von Vorzügen und Nachteilen angemessen.

Nein, den Unterschied zwischen TB und TiB sollte man schon kennen, auch wenn Windows diese nicht zu kennen scheint. 8x8TB in einem RAID5 erben 7x8TB = 56TB = 50,9TiB Nutzkapazität. Außerdem können HW RAID Controller RAIDs auch um neuen HDDs erweitern, die danach gleichberechtigte Member des RAIDs sind, was z.B. ZFS nicht kann. Es reicht also die anfangs erforderliche Kapazität anzuschaffen, dann kann man immer noch anbauen.

Troll?
Lenk nicht ab... Mal davon abgesehen, in der Zeit, als ICH in die IT eingestiegen bin, gab es diese neue Modeerscheinung dieser Maßeinheiten nicht. Ich werde es also für mich auch nicht ablegen. Es hat früher jeder verstanden und es wird auch weiterhin jeder verstehen, der gewillt ist, es zu verstehen. Mal davon ab, von Jemanden, der angeblich so viel "Ahnung" hat wie du, hätte man erwarten können, dass dir der Umstand durchaus geläufig ist, wo doch nachträglich eingeführte Maßeinheiten/Änderung der Bedeutung von Maßeinheiten Jahre/Jahrzente seit Beginn der Nutzung an der Grundaussage nichts ändern...
Was du mit ZFS nun willst, ist mir auch rätzelhaft... Der Rest? Ebenso nicht dem Thema zugehörig... Aber schön zu sehen, wie du schon wieder anfängst dich rauszureden Wen interessiert die Frequenz der Vibration bei der Aussage, es gibt nicht nur HDDs, die für Vibrieren sorgen?

Und warum?

Weil es Ausfälle nicht ausschließlich nach der Warscheinlichkeitsrechnung anhand des UBER Wertes gibt...
Worauf willst du denn genau hinaus? -> du nennst sogar nunmehr explizit die Unterschiede zwischen einer Raid5 und 6 Kombo nach Hinweis von mir.
Dazu kommt, rein von dieser Warscheinlichkeit, 62%, dass ein Rebuild erfolgreich ist, bekommt keine Empfehlung... Aus meiner Sicht kannst du dir das Raidlevel an der Stelle komplett schenken. Denn statistisch gesehen bei zwei von drei Rebuilds muss man das Backup bemühen. Und das soll ernsthaft empfohlen werden???

 

[Holt]

Die Wahrscheinlichkeit eines Komplettausfalles einer HDD während des Rebuilds habe ich nicht einbezogen, aber selbst bei einer AFR von 2%, also einer Wahrscheinlichkeit von 2% das innerhalb von 365 Tage eine der HDDs ausfällt, ist für den einen Tag den so ein Rebuild dauert im Vergleich zur Wahrscheinlichkeit eines Lesefehler vernachlässigbar. Diese wäre beim Rebuild eines RAID6 zu berücksichtigen, da dort die Wahrscheinlichkeit das zwei Platten ausgerechnet an der gleichen Stelle einen Lesefehler aufweisen, eben vernachlässigbar gering ist.

Das die Chance aufgrund der UBER ein theoretischer Wert ist, darauf haben ich ebenso hingewiesen wie auf die Tatsache, dass diese für ein RAID 5 eben deutlich unter den fast 100% für ein RAID 6 liegt, empfohlen habe ich weder das eine noch das andere, sondern eben darauf verwiesen wie die Chancen sind und nicht diesen Blödsinn nachgeplattert, dass man sowas keineswegs machen sollte und es nie gutgehen kann, denn wer so einen Mist verbreitet, der hat bestimmt die UBER dabei nicht berücksichtigt. Die bedeutet übrigens auch, dass schon ein RAID 1 auf zwei 6TB HDDs mit einer UBER von 1:10^14 wie also z.B. den WD Red dann nur noch eine theoretische Chance von 50% auf ein erfolgreiches Rebuild hat, warnen die gleichen Leute auf davor sowas zu machen?

Leider kann man Mods ja nicht auf die Ignorliste setzt, sonst wärst spätestens jetzt einer mehr drauf, Antworten werden ich aber nicht mehr.

 

[fdsonne]

Die Wahrscheinlichkeit eines Komplettausfalles einer HDD während des Rebuilds habe ich nicht einbezogen, aber selbst bei einer AFR von 2%, also einer Wahrscheinlichkeit von 2% das innerhalb von 365 Tage eine der HDDs ausfällt, ist für den einen Tag den so ein Rebuild dauert im Vergleich zur Wahrscheinlichkeit eines Lesefehler vernachlässigbar.

Der Schuh wird aus meiner Sicht genau andersrum draus... Es kommt meiner Erfahrung nach vergleichsweise häufig vor, dass da mal Disks komplett aussteigen. In Zahlen können das von mir aus 2% sein. Bringt dem TE doch aber nix, wenn er nun genau davon betroffen ist/wäre? Keines der Storagesysteme, die ich hier unter meiner Fuchtel habe, hat es bis dato geschafft, mehr als 3 Jahre komplett ohne Diskausfall zu überleben! KEINS... Und das bei zum Teil Enterprise Disks, die es von der Spefizikation eigentlich hätten bringen dürfen... Und eben mit hohen UBER Werten, teils wirklich winzigen Disks/Arrays (sowas wie 300GB SAS Disks zu 10+2 Disks). ALLE samt haben da minimum einen Ausfall auf dem Kerbholz. Plattenhersteller gehen wild durch den Gemüsegarten, Storagesystemhersteller ebenso... Kurzum, die Praxis scheint mir da was anderes zu bescheinigen als die Theorie
Ebenso ein Grund, warum ich sagte, UBER ist nicht alles...

Und warum andersrum? Mir ging es in der Aussage eher darum zu bedenken, dass ein Disk Totalausfall der Grund für den Rebuild ist -> und dann während des Rebuilds der Lesefehler auftaucht... Das dürfte (ohne jetzt genaue Zahlen vorweisen zu können) recht warscheinlich sein und häufige Ursache für ein Totalausfall des Arrays. Auch weil es wohl recht selten vorkommt, das der komplette Arrayinhalt zyklisch komplett gelesen wird. Sprich man bekommt idR den Lesenfehler erst dann mit, wenn man den Inhalt komplett ließ -> wie eben bei einem Rebuild. Auch Backups werden wohl selten bis gar nicht in dieser Größenordnung zyklisch den vollen Datenbestand, am Besten noch binär vergleichen...

Zum Rest, sorry Holt, aber du schreibst das da: "Damit wäre selbst ein RAID 5 mit 8 x 8TB zu verantworten, denn bei einer UBER von 1:10^15 hat man dann immer noch eine theoretische Chance von fast 62% auf ein erfolgreiches Rebuild, und da RAIDs keine Backups ersetzen, sollten entweder die Daten nicht so wichtig sein oder es ein Backup davon geben."

Auf welcher Basis frage ich mich? Dafür hast du die Kritik kassiert. Ich kann mich nur widerholen. Auf den Spezifkationen rumzupochen und dann mit einem Raid5 um die Ecke zu kommen, was in der konkreten Konstellation eigentlich nicht mehr wirklich verantwortbar wäre (aus meiner Sicht) ist nunmal kritikwürdig, weil Messen mit zweierlei Maß.
Den Rest, das ganze Gesabbel, schenk es dir... Es bringt nix und ist wenig sachlich


PS: was mich dazu noch interessieren würde, welche konkreten HDD Raid5 Umsetzungen mit 8x Disks bekommen von dir denn noch so eine Empfehlung? UBER von 1:10^15 sind ja schon recht "hoch" im Vergleich zur Diskgröße bei den geannten Modellen.
Also ich sehe da eher 99% der Fälle, wo ein Raid5 mit 8x Disks eher zu vermeiden ist bzw. ein Raid6 mit 8x Disks (ggf. unter anbetracht der nächt höheren Größe) die sinnigere Wahl ist... Und damit die Pauschale durchaus seine Richtigkeit hat. Gern darfst du mir das Gegenteil belegen

Kostenfaktor natürlich dabei außen vor... Aber der TE hat sich weder zum Preis noch zum Platzbedarf geäußert. Die Raid5 Aussage deinerseits ist dahingehend also ebenso... Lassen wir das. Es gab mindestens mal keinen Grund, sich auf 8x8TB im Raid5 einzufahren

 

[mika2004]

Nein, Deine Aussagen sind generell mit Vorsicht zu genießen, aber als Mod kannst Du es Dir erlauben,

Dieser Satz ist mehr als nur eine Frechheit.
Aber Herabwürdigungen von anderen Usern gehören zum Spektrum von Holt.

So langsam habe ich das Gefühl,
der User Holt lebt in seiner eigenen Welt,
in der nur er das absolute Wissen besitzt.

UBER (was immer UBER auch bedeutet, Seagate nennt es "Non-recoverable read error")
ist lediglich eine Klassifizierung.
Der Spielraum zwischen 14TB (10^14) und 144TB (10^15) ist riesengroß.

Deshalb kann eine Platte 1xNRE auf 120TBR erfüllen, fällt damit aber trotzdem die Klassifizierung "10^14".
Eine Wahrscheinlichkeitsrechnung aufgrund von 10^14 ist völliger Blödsinn.

 

[Digi-Quick]

Das gemeine an Wahrscheinlichkeitsberechnungen ist, daß sie nicht die Wirklichkeit wiederspiegeln, sondern nur auf statistischen Daten beruhen.
Die URE (unrecoverable Read Errror) oder auch Non recoverable Read Error ist ein solcher statistischer Wert.
Dieser besagt, daß statistsch gesehen pro x gelesener Bits ein Lesefehler auftreten kann. Er besagt aber keiner Weise wann ein Lesefehler auftritt. Das kann zu jeder Zeit passieren.
Die Wahrscheinlchkeitsrechnung bietet keinerlei Garantie!

 

[mika2004]

Das gemeine an Wahrscheinlichkeitsberechnungen ist, daß sie nicht die Wirklichkeit wiederspiegeln, sondern nur auf statistischen Daten beruhen.
Die URE (unrecoverable Read Errror) oder auch Non recoverable Read Error ist ein solcher statistischer Wert.
Dieser besagt, daß statistsch gesehen pro x gelesener Bits ein Lesefehler auftreten kann. Er besagt aber keiner Weise wann ein Lesefehler auftritt. Das kann zu jeder Zeit passieren.
Die Wahrscheinlchkeitsrechnung bietet keinerlei Garantie!

Hier möchte ich widersprechen.
Es handelt sich nicht um einen statistischer Wert, sondern um eine Klassifizierung.

Es gibt nach meinem Wissen nur zwei Werte 10^14 und 10^15.
Das ist viel zu wenig für einen "Statistischen Wert".

 

[MrDeluxe]

Schön, dass dieses Thema UBER / URE angesprochen wird. Ich zerbreche mir selber gerade den Kopf ob ich nun zur WD Red 8TB greifen sollte mit 10^14 oder eben weitersuchen soll. Betreiben würde ich davon 8 Stück im Raid6 Verbund. Mich persönlich würde interessieren, wie die Hersteller überhaupt so eine Klassifizierung durchführen können. Denn an und für sich ist es ein kritisches Qualitätsmerkmal für NAS-Festplatten. Je höher der UBER / URE desto teurer könnte ich die HDD verkaufen. Als Endnutzer/Storage-Betreiber kann ich dem Hersteller aber dennoch nicht ans Bein pinkeln, nur weil die HDD mit 10^15 vorher ausgestiegen ist als die mit 10^14.
Was mir zusätzlich aufgefallen ist. Dieser Parameter ist oftmals gar nicht vermerkt wurde. Ich suche verzweifelt nach der Bitfehlerrate meiner alten Samsung HD204UI. Unauffindbar. Gab es diesen Parameter vor 7Jahren überhaupt?
Man könnte rund um dieses Thema einen eigenen Thread bauen, was Mythen und Fakten betrifft. Das würde wohl einige NAS-HDD-Käufer freuen.

 

[Digi-Quick]

Es gibt sogar 10^16 - bei SAS HDDs.
Auch wenn HDDs nach URE klassifiziert werden, so bleibt es trotzdem ein statistischer Wert.

 

[MrDeluxe]

Und woher stammen die statistischen Werte? Aus den Hersteller-Laboren? Wird das hochgerechnet? Inwiefern sollte man sich auf diesen Wert verlassen beim Kauf?

 

[Holt]

MrDeluxe, auch vor 7 Jahren gab es die UBER schon, aber für eine 7 Jahre alte Platte gilt die Angaben sowieso nicht mehr, da diese die Spezifikation bzgl. der geplanten Nutzungsdauer längst verlassen hat. Bei mehr oder weniger allen Samsung HDDs stand es so oder ähnlich in den Datenblättern:

Component Design Life: 5 years

Das ist zwar noch älter als die HD204UI, aber schon dort findet sich auch die UEBR (ob man nun Uncorrectable Bit Error Rate oder Non-recoverable Read Error Rate sagt, es egal, UBER ist am gebräuchlisten, auch wenn dabei viele an einen Taxidienst denken):

Non-recoverable Read Error 1 sector in 10^14 bits

Leider finde ich das entsprechende Dokument für die HD204UI auch nicht, aber im RAID 6 ist wie gesagt die UBER recht egal, da das Risiko das zwei HDDs am Sektor einen Lesefehler haben werden, verschwindet gering ist, da spielt das Ausfallrisiko der Platten dann schon eine größere Rolle.

Wie weit man sich auf die UBER verlassen kann, hängt davon ab ob man die Platten innerhalb der Spezifikationen betreibt. Dann treten die Fehler auch nicht garantiert auf, sondern sind eben mit bis zu dieser Häufigkeit möglich ohne das die HDD ihre Spezifikationen verletzt. Die Hersteller haben da verschiedene Möglichkeiten wie z.B. die Länge und Algorithmen der ECC um den Wert zu beeinflussen und natürlich ist ein besserer Wert auch mit einem größeren Aufwand verbunden. Letztlich ist es aber bei allen Werten die mit Wahrscheinlichkeiten zu tun haben so, dass es nichts darüber aussagen kann was im individuellen Fall passieren wird, sonst würde ja keine mehr Lotto spielen, weil es eben extrem unwahrscheinlich ist den Jackpot abzuräumen und doch schafft es immer wieder mal jemand.

 

[MrDeluxe]

Leider finde ich das entsprechende Dokument für die HD204UI auch nicht, aber im RAID 6 ist wie gesagt die UBER recht egal, da das Risiko das zwei HDDs am Sektor einen Lesefehler haben werden, verschwindet gering ist, da spielt das Ausfallrisiko der Platten dann schon eine größere Rolle.

Gibt es für das Ausfallrisiko auch eine Art Parameter? Wenn Uber bei Raid6 keine Rolle spielt, kann ich dann nach belieben eine NAS-HDD aussuchen, die meinen Wünschen entspricht unabhängig nach deren Verlässlichkeit? Ich würde dann nur noch nach Geschwindigkeit, Verbrauch, Lautstärke und Preis schauen.

 

[Holt]

Das Ausfallrisiko wird im Prinzip von der MTBF angegeben, die gilt aber auch nur unter bestimmten Bedingungen und vor allem nur über einen bestimmten Zeitraum. Seagate schreibt dazu:

MTBF is typically calculated during an HDD’s useful life
...
MTBF remains a difficult metric to use properly, in part because it is based more on extrapolation than observation.
...
Recently, Seagate began offering AFR specs on some drives in addition to conventional MTBF ratings. Although the two metrics are similar, AFR is a percentage estimate of the products that will likely fail due to a defect over a 1-year period. The subtle distinction lies in a switch from averages to percentages. MTBF is based on probabilities; AFR relies on HDD return numbers and analyses for its estimates. AFRs don’t include HDDs returned without issues, those subjected to excessive shock or HDDs that were mishandled.

Meines Wissens wird für die MTBF auch die Anfangszeit ausgenommen, in der ja die Ausfallraten technischer Geräte immer besonders hoch sind.

 

[MrDeluxe]

Viele NAS-HDDs haben ein MTBF von ca. 1Mio. Stunden.

-> ~114 Jahre

Was ist denn die "Anfangszeit" 1 bis 2 Jahre?

 

[Holt]

Die MTBF wird zwar in Stunden angegeben, ist aber eine Ausfallwahrscheinlichkeit und kann keineswegs in eine Lebenserwartung umgerechnet werden.
Wieso das so ist? Nun ein durchschnittlicher Mitteleuropäer von 46 Jahren mit einem BMI von 27, Nichtraucher und mäßiger Konsument von Alkohol hat eine statistische Sterberate von 1,8 Todesfällen pro 1000 solcher Personen. Damit rechnen die Versicherungen und daraus ergibt sich eine MTBF von 1000(Personen) * 365 (Tage/Jahr) * 24 (Stunden/Tag) / 1,8 (Personen, die Ausfälle pro Jahr) = 4,867 Millionen Stunden, was 555 Jahren entspricht.
So alt wird aber offensichtlich keiner, die Versicherer rechnen mit 81 Jahren Lebenserwartung, also nur etwa 0,71 Millionen Stunden.