Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsFestplatten: WD Red (Pro) und WD Purple erhalten 8 TB und Helium
Ist die Lautstärke im Idle wirklich so extrem? WD gibt bei der WD80EFZX 20dB an, während es bei der WD60EFRX 25dB sind. Wäre also davon ausgegangen, das die neue Heliumplatte merklich leiser ist. Stand eigentlich auch kurz davor, mir vier stück für meine DS415+ zu holen.
Wenn die aber wirklich so laut sind, werd ich wohl doch auf die WD60EFRX setzen.
e: Und wenn wir schon dabei sind.. Hat die WD80EFZX auch das für HGST Platten typische, regelmäßige "klickgeräusch"?
Ich habe mir 6 Stück von den WD80EFZX geholt. Im Vergleich zu den WD60EFRX sind sie brutal laut und vibrieren enorm. Besonders das Zugriffsgeräusch habe ich in einer solchen Lautstärke noch nicht gehört.
Ist ja offensichtlich HGST-Technik. Das passt dann ein bisschen.
Ich habe letztens eine HGST 7K6000 6 TB eingebaut (kein Helium). Die vibriert zwar praktisch gar nicht, aber die Kopfbewegungen sind auch "brutal laut". Verbaut mit Silikonpuffern im gedämmten Gehäuse und trotzdem wird teilweise das Gehäuse zum Klappern angeregt.
So klangen Festplatten vor 20 Jahren vielleicht mal.
Eine gleichzeitig verbaute WD black 6 TB ist viel viel leiser bzgl. der Kopfbewegung (vibriert aber mehr).
Die Zugriffszeiten sind praktisch gleich bei den Platten, die HGST ist also irgendwie grundlos laut.
Ich halte die ganzen UBER Angaben und dazu gemachte Rechnungen nicht vertrauenswürdig.
Die sind ja offensichtlich keine belastbaren Werte, die technischen Daten widersprechen sich schon.
Die Enterprise Platten werden mit 1 Fehler 1e15 angegeben. Das würde also heißen ein Fehler alle ca. 120 TB.
Bei einer auch spezifizierten Workload von 550 TB/Jahr, wären das mehrere Fehler pro Jahr.
Gleichzeitig geben die aber MTBF und AFR an, die Jahre fehlerfreie Arbeit bescheinigen.
Okay, möglicherweise wird hier Fehler und Fehler anders definiert, aber dazu habe ich bisher nur Aussagen gefunden, die so ungefähr so sind: "Was ein Fehler ist wird sehr verschieden interpretiert".
@klampf: Dafür macht man ja Data Scrubbing. Und das ist auch der Grund, warum ich mein großes Volume auf dem NAS auf RAID-6 umgestellt habe. Ob nun 1*10^14 oder 1*10^15 - je nach Anwendungszweck sind die schnell erreicht. So zum Beispiel bei mir mit 6 Platten und 24 TB, davon 16 TB Nettokapazität bereits statistisch gesehen 1-2 Fehler bei einem einzigen Rebuild des RAIDs. Das heißt es liegt durchaus im Bereich des möglichen.
Im Normalbetrieb spielt das keine so große Rolle. Vereinfacht erklärt: Tritt ein Lesefehler auf oder wird ein Sektor falsch geschrieben, so wird dies beim DATA Scrubbing auch beim RAID 5 schon festgestellt. Die Daten und die Prüfsumme passen nicht zusammen. Da nun aber weder ein Controller noch eine Software entscheiden kann, ob von beiden nun Daten oder Prüfsumme jeweils falsch oder richtig sind, wird auf die Redundanzinformationen zurückgegriffen. In dem Fall hat man dann bei 2 von 3 Datensätzen (Daten, CRC, Redundanzinformation) Übereinstimmung, und somit eine Bestätigung. Anschließend wird der Fehler korrigiert.
Ein Problem bekommt man aber, wenn im RAID 5 eine Platte ausfällt, ersetzt wird, und ein Rebuild gestartet wird. In dem Fall ist nämlich bereits alles an Daten nur noch praktisch als Daten + CRC oder als Redundanz + CRC vorhanden. Somit kann zwar ein Fehler festgestellt, aber nicht korrigiert werden, da nicht bestätigt werden kann welches nun richtig ist.
Daher habe ich nun ein RAID-6, da somit bei Ausfall einer Platte, und laufendem Rebuild, immer noch Datenbestände zum Abgleich von Fehlern vorhanden sind. Daher macht es durchaus Sinn, bei großen Arrays auf Redundanz mehrerer Platten zu setzen. Eine ist definitiv zu wenig. Mal ganz abgesehen natürlich vom erhöhten Ausfallrisiko wenn man das Array beim Rebuild noch stresst und somit auch das Risiko für den Ausfall weiterer Platten nicht unrealistisch ist.
Das musst Du wissen, aber ich finde es noch im vertretbaren Bereich und die Angabe sind auch kleiner gleich 1:10^1x, damit sind die theoretischen Chancen dann Worst-Case, sofern man den Angaben trauen kann, weil man die HDDs innerhalb der Spezifikationen betreibt und sie nur misshandelt wurden.
Andi316 schrieb:
Wie hoch ist die Wahrscheinlichkeit eines erfolgreichen Rebuilds bei Raid 5 mit 5 Reds?
Bei den 8TB wäre es mit der UBER von 1:10^14 dann nur noch 1,2%. Vergiss nicht, bei einer solche UBER dürfte je etwa 12TB gelesener Daten ein unkorrigierbarer Sektor auftreten, also ein schwebende Sektor entstehen und ein Lesefehler zurückgegeben werden, was noch innerhalb der Specs liegen würde. Die Chance eine einzelne Platte komplett fehlerfrei zu lesen ist also nur (12-8)TB/12TB = 0,667 bzw. 66,7% und um ein RAID 5 aus 5 HDDs zu rebuilden müssen 4 HDDs komplett fehlerfrei gelesen werden, also 0,667^4 und das ist nur noch 0,012 also 1,2%.
Bei einer UBER von 1:10^15 darf so ein Fehler nur pro etwa 120TB gelesener Daten auftreten und damit ist die Rechnung dann (120-8)TB/120TB und Chance pro Platte somit 0,933 bzw. 93,3% und bei 4 HDDs eben 0,933^4 = 0,759 bzw. 75,9%. Wie man sieht ist die UBER umso wichtiger, je größer die Platten wird und je näher ihre Kapazität damit an die Datenmenge kommt, bei der statisch ein Fehler auftreten kann. Bei 12TB Kapazität wären Platte mit einer UBER von 1:10^14 nicht mehr praktikabel, man könnte zu zumindest theoretisch gar nicht mehr komplett fehlerfrei auslesen.
Umgekehrt kann man mit den 2.5" Enterprise HDDs mit 15.000 rpm die eine UBER von 1:10^16 haben, dann schon große RAID 5 bauen, die Kapazität beträgt bei denen ja maximal 600GB und ein Fehler ist nur alle 1200TB wahrscheinlich, man kann die HDD also im Schnitt zwischen den Fehlern 2000mal komplett auslesen! Die Wahrscheinlichkeit das man eine Platten fehlerfrei lesen kann, liegt damit bei 0,9995 und selbst 0,9995^25 sind noch immer 0,9876, also 98,8% Wahrscheinlichkeit ein RAID 5 aus 26 solcher HDDs zu erfolgreich rebuilden.
klampf schrieb:
die Kopfbewegungen sind auch "brutal laut". Verbaut mit Silikonpuffern im gedämmten Gehäuse und trotzdem wird teilweise das Gehäuse zum Klappern angeregt.
So klangen Festplatten vor 20 Jahren vielleicht mal.
Eine gleichzeitig verbaute WD black 6 TB ist viel viel leiser bzgl. der Kopfbewegung (vibriert aber mehr).
Das hat mit vor 20 Jahre nichts zu tun, die Enterprise HDDs klangen immer so, die werden die Köpfe extremer beschleunigt und schneller abgebremst um die Zugriffszeiten geringer zu halten. Bei Consumer- und vor allem Desktopplatten wird das weicher gemacht, was zwar Zeit kostet, aber leiser ist, weil die Kunden das eben so wollen und außerdem erzeugt es weniger Vibrationen, gegen die sind solche HDDs ja auch weniger gut abgesichert bzw. Desktopplatten i.d.R. eben gar nicht.
klampf schrieb:
Die Zugriffszeiten sind praktisch gleich bei den Platten, die HGST ist also irgendwie grundlos laut.
Die Unterschiede mögen für Dich klein sein, aber andererseits sind die Prioritäten eher andere. Welche hast Du denn, die Ultrastar? Die sind zwar für den Einsatz im Desktop oder NAS tauglich, aber eben nicht darauf optimiert, sondern eben auf maximale Performance und den Einsatz in einem Rechenzentrum und dort ist es sowieso laut und da hält sich auch normalerweise keiner drin auf.
klampf schrieb:
Ich halte die ganzen UBER Angaben und dazu gemachte Rechnungen nicht vertrauenswürdig.
Das ist Deine Sache und wie genau die Angaben Hersteller stimmen, hängt natürlich auch von den Einsatzbedingungen ab, aber was schwebende Sektoren sind und das es sie gibt, ist Dir doch sicher auch bekannt. Wie die Berechnung der Rebuildwahrscheinlichkeit für ein RAID 5 gemacht wird, siehst Du ja nun hier.
klampf schrieb:
Die sind ja offensichtlich keine belastbaren Werte, die technischen Daten widersprechen sich schon.
Wo widersprechen sich welche Angaben denn konkret?
klampf schrieb:
Die Enterprise Platten werden mit 1 Fehler 1e15 angegeben. Das würde also heißen ein Fehler alle ca. 120 TB.
Bei einer auch spezifizierten Workload von 550 TB/Jahr, wären das mehrere Fehler pro Jahr.
Richtig, aber der Workload ist auf das Volumen der gelesenen und der geschriebenen Daten bezogen! Die UBER bezieht sich nur auf die gelesenen Daten und da muss man eben, wenn man z.B. 480TB pro Jahr liest, mit 4 Lesefehler pro Jahr rechnen, damit bleibt die HDD innerhalb der Spezifikationen. Das Auftreten der Fehler sind aber nicht garantiert, wenn man Glück hat, gibt es keinen Fehler, es steht ja meist <= davor und selbst wenn nicht, dann ist der Wert trotzdem so zu interpretieren. Auf einem runden Verkehrsschild mit roten Rand steht ja auch nur 100 und jeder Verkehrsteilnehmer muss wissen, dass 100km/h gemeint sind und dies die Höchstgeschwindigkeit angibt, er aber auch langsamer fahren darf. Bei dies ist die höchste die Platte bei korrekten Einsatzbedingungen und fachgerechter Handhabung im Schnitt über eine große Population zeigen darf.
klampf schrieb:
Gleichzeitig geben die aber MTBF und AFR an, die Jahre fehlerfreie Arbeit bescheinigen.
Nein, die MTBF wird zwar in Stunden angegeben, ist aber eine Ausfallwahrscheinlichkeit und kann keineswegs in Betriebsstunden umgerechnet werden, bescheinigt damit auch keine Lebenserwartung und Lesefehler sind dafür nicht relevant, die gehören innerhalb der UBER zum normalen Betrieb. Wenn also ein Lesefehler und damit schwebender Sektor im Betrieb anfällt, dann ist das kein Ausfall, dies zu glauben ist ein verbreiteter Blödsinn, diese Lesefehler sind normal und kein Ausfall der für die MTBF oder AFR relevant wäre.
Profis nutzen auch deshalb immer RAIDs, echte RAID wo das R für Redundant auch berechtigt ist und kein RAID 0, welches eigentlich ein AID 0 ist. Dann macht so ein Lesefehler auch gar nichts, der Controller stellt die Daten mit Hilfe der Parity wieder her und schreibt sie auf die Platte zurück, die daraufhin die Daten nach dem Schreiben auch noch prüft und dann ggf. einen Reservesektor verwendet, wenn wirklich ein Schaden an der Oberfläche vorliegt und selbst dann ist es noch kein für die MTBF bzw. AFR relevanter Fehler, da dieses Verhalten so vorgesehen ist und erst wenn die Anzahl der benutzten Reservesektoren massiv ansteigt, wird es auch bzgl. eines Totoalausfalls kritisch und dann erst wird es für die MTBF / AFR relevant.
Vergiss also die Hysteriker die bei jedem benutzten Reservesektor das baldige Ende der HDDs voraussagen, die haben meist nur deswegen recht, weil dies häufig die Folge einer Misshandlung der Platte ist, denn wie empfindlich HDDs sind und wie man damit korrekt umzugehen hat, zeigt ja dieses Video von HGST und weist auch darauf hin, dass die Schäden sich auch erst später bemerkbar machen können. Bei den meisten Heimanwendern dürften die HDDs kaum entsprechend sorgsam behandelt werden und wenn der PC dann auch noch mal im Betrieb einen kräftigen Tritt bekommen hat, dann sollte man sich über defekte Sektoren und einen baldigen Ausfall nicht wundern, die sind dann das Zeichen für den mechanischen Schaden, aber es ist eben nicht generell so, dass jede HDD bei der es mal auftritt, den auch einen mechanischen Schaden haben muss. Bei Heimanwendern aber vermutlich häufiger als bei echten Profi Storages wo sie Platten in den 19" Racks werkeln und mechanisch in Ruhe gelassen werden.
Wie viele der bei Heimanwendern "verstorbenen" HDDs also eigentlich eher als "ermordet" (ok, gefährliche Körperverletzung mit Todesfolge) wurden, möchte ich gar nicht wissen aber vermutlich viele. Zumindest viele von denen die bald nach dem ersten problematischen Sektor ganz kaputt waren.
klampf schrieb:
Okay, möglicherweise wird hier Fehler und Fehler anders definiert, aber dazu habe ich bisher nur Aussagen gefunden, die so ungefähr so sind: "Was ein Fehler ist wird sehr verschieden interpretiert".
Das ist korrekt und da man das typische Verhalten der Industrie kennt ihr Produkte immer in einem guten Licht dastehen zu lassen, kannst Du davon ausgehen, dass die Kriterien für einen Ausfall dort großzügig sind und sicher nicht mit Deiner Definition übereinstimmen, die schon jeden schwebenden Sektor mitzählt.
Jein, das Scrubbing ist ist um schwebende Sektoren zu finden und zu beheben, denn das sind ja Sektoren deren Daten nicht mehr zur ECC passen. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Gerade letzteres kann bei RAIDs auch mal vorkommen, vor allem wenn man keine Platten mit ausreichenden Schutzmaßnahmen gegen Vibrationen einsetzt.
Krisch werden die erst, wenn z.B. beim RAID 5 die gleiche Adressen auf 2 Platten betroffen sind und damit die Wahrscheinlichkeit dafür gering bleibt, macht man eben Scubbing und bitte nicht zu oft, nicht selten findet man im Netz die Empfehlung es wöchentlich pro cron-job einzustellen, denn dabei ist der Workload dann sehr hoch. WD gibt es für die Red nicht an, im Netz geistern so 130TB/Jahr rum, die Seagate NAS hat 180TB/Jahr und wenn man dann eine 4TB wöchentlich einmal liest, sind diese auch überschritten.
NobodysFool schrieb:
Ob nun 1*10^14 oder 1*10^15 - je nach Anwendungszweck sind die schnell erreicht. So zum Beispiel bei mir mit 6 Platten und 24 TB, davon 16 TB Nettokapazität bereits statistisch gesehen 1-2 Fehler bei einem einzigen Rebuild des RAIDs. Das heißt es liegt durchaus im Bereich des möglichen.
Nein, ob eine HDD nun 1:10^14 oder 1:1^15 hat, macht einen gewaltigen Unterschied. Du hast ja 6 4TB HDDs und hättest damit bei 1:10^14 eine Chance von 13,2% ein RAID 5 zu rebuilden, aber eine von 84,4% bei HDDs mit einer UBER von 1:10^15!
NobodysFool schrieb:
Vereinfacht erklärt: Tritt ein Lesefehler auf oder wird ein Sektor falsch geschrieben, so wird dies beim DATA Scrubbing auch beim RAID 5 schon festgestellt.
Tritt ein Lesefehler auf, dann ja, aber was meinst Du mit falsch geschrieben? Das kann nur passieren, wenn die Oberfläche der Platte an der Stelle unerkannt defekt geworden ist und die Bits daher falsch ausgelesen werden, dann gibt es aber auch wieder einen Lesefehler, denn beim Schreiben werden die Daten gewöhnlich nicht überprüft, dies passiert nur wenn vorher als schwebend erkannte Sektoren überschrieben werden.
NobodysFool schrieb:
Die Daten und die Prüfsumme passen nicht zusammen. Da nun aber weder ein Controller noch eine Software entscheiden kann, ob von beiden nun Daten oder Prüfsumme jeweils falsch oder richtig sind, wird auf die Redundanzinformationen zurückgegriffen.
Sehr vereinfach gesagt und nur bei einem echten RAID möglich oder wenn das Filesystem entsprechende Prüfsummen hat. Denn die Platte selbst hat keine Redundanz außer der ECC hinter jedem Sektor mit der in begrenztem Masse auch Bitfehler korrigiert werden können und sonst meldet sie eben einen Lesefehler zurück, aber gewöhnlich senden HDDs nie inkorrekte Daten zurück. Der Lesefehler wird vom RAID zu Anlass genommen die Daten zu rekonstruieren und die Daten auf der betroffenen Platte zu überschreiben.
NobodysFool schrieb:
In dem Fall hat man dann bei 2 von 3 Datensätzen (Daten, CRC, Redundanzinformation) Übereinstimmung, und somit eine Bestätigung.
Nein, diese inkorrekten Daten bekommt man wie gesagt nicht von der Platten, außer wir reden von SAS HDDS, da kann es sein wenn der RAID Controller diese entsprechend ansteuert, dann formatiert er sie aber auch mit 520 oder 528 Bytes pro LBA statt mit 512 und schreibt in die zusätzlichen 8 bzw. 16 Bytes eine eigene Prüfsumme um Lesefehler sofort selbst zu erkennen, damit erspart man die Verzögerung durch wiederholte Leseversuche der HDD und dazu werden auch andere Befehle im Befehlssatz verwendet. Bei SATA Platte ist das aber nicht möglich.
Genau und daher spielen solche Fehler dann auch keine Rolle.
NobodysFool schrieb:
Ein Problem bekommt man aber, wenn im RAID 5 eine Platte ausfällt, ersetzt wird, und ein Rebuild gestartet wird. In dem Fall ist nämlich bereits alles an Daten nur noch praktisch als Daten + CRC oder als Redundanz + CRC vorhanden. Somit kann zwar ein Fehler festgestellt, aber nicht korrigiert werden, da nicht bestätigt werden kann welches nun richtig ist.
Auch hier hat man bei SATA Platten nicht die falschen Daten, denn man wird stattdessen einen Lesefehler von der Platte bekommen. Damit bricht ein Rebuild i.d.R. eben ab und das RAID ist dann nicht mehr nur degraded sondern offline.
Das hängt aber von den Platten ab, bei denen mit einer UBER von 1:10^16 sind auch RAID 5 mit über 20 HDDs kein Problem und ein RAID 6 hat ja auch eine noch größere Write Penalty. Pauschalaussagen sind wie immer hier nicht angebracht, weil im Zweifel eben auch total falsch.
Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese zu lesen.
Ja so war das auch gedacht. Ich habe ja nicht geschrieben daß die Platte dann falsche Daten liefert. Sobald Daten und Prüfsumme nicht mehr zusammenpassen ist nach paar Versuchen Schluß. Auch auf die etlichen möglichen Gründe dafür bin ich gar nicht genauer eingegangen, darum gings ja primär gar nicht.
Holt schrieb:
Nein, ob eine HDD nun 1:10^14 oder 1:1^15 hat, macht einen gewaltigen Unterschied. Du hast ja 6 4TB HDDs und hättest damit bei 1:10^14 eine Chance von 13,2% ein RAID 5 zu rebuilden, aber eine von 84,4% bei HDDs mit einer UBER von 1:10^15!
Ich habe aber aus genau dem Grund eben kein RAID-5 sondern ein RAID-6. Und somit sind beim Rebuild einer einzigen Platte noch Redundanzinformationen vorhanden, mit denen sich eben solch ein Fehler beheben lässt.
Holt schrieb:
... aber gewöhnlich senden HDDs nie inkorrekte Daten zurück. Der Lesefehler wird vom RAID zu Anlass genommen die Daten zu rekonstruieren und die Daten auf der betroffenen Platte zu überschreiben. Nein, diese inkorrekten Daten bekommt man wie gesagt nicht von der Platten ...
Auch hier hat man bei SATA Platten nicht die falschen Daten, denn man wird stattdessen einen Lesefehler von der Platte bekommen. Damit bricht ein Rebuild i.d.R. eben ab und das RAID ist dann nicht mehr nur degraded sondern offline.
Der Rebuild bricht eben nicht ab, wenn es sich eum ein RAID-6 handelt und der Rebuild nur über eine Platte geht. Es ist ja dann immer noch Parity auf einer Platte vorhanden, und somit Alternativmöglichkeiten den betroffenen Sektor zu lesen.
Da lag überhaupt die ganze Absicht meines Posts, nämlich zu zeigen, daß eine OBER von 1*10^14 kein Beinbruch sein muß, wenn man dies entsprechend berücksichtigt. Natürlich kann man das auch mit Platten mit geringerer Fehlerwahrscheinlichkeit auch lösen und dann durchaus wieder ein RAID-5 benutzen. Wenbn man das aber mit den Platten erreichen will die man hat, halt bei mir z. B. die 5x WD Red 4 TB, dann bleibt halt nur übrig, noch eine Platte dazu zu nehmen und auf ein RAID-6 zu wechseln. Somit verbessert die zusätzliche Parity zwar nicht die Fehlerrate, aber gibt einem Werkzeuge an die Hand damit Fehler umgangen bzw. korrigiert werden können wenn man so sagen will.
Bei einer Neuanschaffung kann man natürlich gleich einen Satz ensprechender Platten kaufen. Letztens halt auch eine Kostenfrage. Statt 5 neuer Platten nur eine zusätzliche kaufen zu müssen ist halt schon ein Unterschied. Zumal die vorhandenen WD Red auch erst keine 2 Jahre mit eher moderater Nutzung auf dem tacho haben. Somit ist eher zu erwarten, daß die inzwischen gut eingelaufen eher noch eine Weile halten und noch nicht prophylaktisch ersetzt werden müssen.
Ein paar ist gut, man genau den Timeout bei den Platten mit TLER eben einstellen und der ist i.d.R. ab Werk auch auf eine geringeren Wert eingestellt, meist 7s. Das unterschiedet sie eben von denen von denen man sagt sie hätten keine TLER, bei denen kann man es nicht einstellen wie lange sie es versuchen und ab Werk ist meist ein höherer eingestellt, bei den Green meine ist 14s. Ab auch in nur 7s macht selbst eine HDD mit 5400rpm immerhin 630 Umdrehungen, hat also mehr als nur ein paar Versuche!
NobodysFool schrieb:
Ich habe aber aus genau dem Grund eben kein RAID-5 sondern ein RAID-6. Und somit sind beim Rebuild einer einzigen Platte noch Redundanzinformationen vorhanden, mit denen sich eben solch ein Fehler beheben lässt.
Klar, beim RAID 6 ist die Chance auf ein Rebuild wenn nur eine HDD ausgefallen ist, extrem hoch und sehr nahe an 100%.
NobodysFool schrieb:
Da lag überhaupt die ganze Absicht meines Posts, nämlich zu zeigen, daß eine OBER von 1*10^14 kein Beinbruch sein muß, wenn man dies entsprechend berücksichtigt. Natürlich kann man das auch mit Platten mit geringerer Fehlerwahrscheinlichkeit auch lösen und dann durchaus wieder ein RAID-5 benutzen.
Die UBER ist eben neben der Anzahl und Kapazität der Platten der entscheidende Faktor für die Frage ob es ein RAID 6 werden muss, oder man mit einem RAID 5 noch eine vertretbare (die Grenze muss da jeder selbst ziehen) Chance auf ein erfolgreiches Rebuild hat. Das ist auch nur eine theoretische Betrachtung, im Einzelfall kann es immer schief gehen und dann braucht man sein Backup oder auch bei eigentlich nur minimaler Chance klappen, aber vorher die Chance zu kennen mit der es wohl klappen dürfte, ist ja auch nie verkehrt.
NobodysFool schrieb:
Wenbn man das aber mit den Platten erreichen will die man hat, halt bei mir z. B. die 5x WD Red 4 TB, dann bleibt halt nur übrig, noch eine Platte dazu zu nehmen und auf ein RAID-6 zu wechseln.
Wenn man die 5 Red 4TB mit ihrer UBER von 1:10^14 schon hat, dann ist der Wechsel auf ein RAID 6 die besten Wahl um die Chance von 19,8% bei einem RAID 5 zu verbessern. Aber wenn man neu kauft, hat man dann auch 6 HDDs zu je 159€ angeschafft, braucht 6 Einbauplätze, 6 Ports am Controller und eine Lösung die auch RAID 6 unterstützt und hat am Ende nur 16TB Nettokapazität. Da finde ich die Anschaffung von 4 Seagate NAS 6TB zu je 253€ auch nicht unattraktiv, da man damit eben mit 4 Bays/Einbauplätzen auskommt und auch ein RAID 5 mit 85,7% Chance auf ein Rebuild und 18TB Nettokapazität machen kann. Gerade wenn man sich dazu noch ein NAS, einen Microserver oder eine Selbstbaulösung anschaffen muss, spart man bei 4 Bay Lösungen dort auch noch einiges ein bzw. hat mehr Auswahl mit/an kompakteren Gehäusen.
Die Western Digital WD Red Pro 8TB (WD8001FFWX) ist im Idle wirklich absolut leise, man könnte sie glatt lautlos auf der Schreibtischplatte betreiben - aber bei Zugriffen hört man sie doch deutlich - ein Fall für ein gutes Festplatten-Dämmgehäuse, wenn man sie in einem Desktop-PC lautlos betreiben möchte.
Hier mal ein Screenshot mit HD Tune Pro (es gibt noch keinen Test dieser Platte im Internet):
Dieser Thread ist aus dem Jahr 2016 und ich frage mich, ob die hier neu angekündigten EFZX Festplatten mit 128 MB Cache jemals auf den Markt gekommen sind? Hat von euch mal jemand so eine wo gekauft?
Ganz sicher? Laut der Geizhals Preisstatistik gab es die noch nie, aber sie kommen offenbar im März 2021 ganz neu raus, von den technischen Daten evtl. als Nachfolger der EFRX? 🤔
Es gibt bei eBay diverse gebrauchte WD80EFZX mit echten Fotos. Laut aufdruckten Herstellungsdaten von Februar 2016 bis Dezember 2017 alles dabei... Habe nach der 6. Auktion nicht mehr weiter gesucht...
Dass diese Reihe die noch ältere EFRX ablöst, glaube ich nicht. Erstens gibt es EFRX eh nur bis 6 TB und zweitens hat WD Helium schon überall abgeschafft wo es zum Erreichen der jeweiligen Kapazität nicht mehr nötig ist. 8 TB und inzwischen ab auch 10 TB gibt es mittlerweile fast nur noch mit Luftfüllung... Helium ist derzeit nur noch ab 12 TB durchgehend anzufinden...
Scheinbar trifft das nur auf die WD 8TB WFZX zu, dass es die mal gab.
Aber siehe meine Links oben, diese Platten sind erst seit einigen Tagen gelistet und derzeit bei allen Händlern im Zulauf.
Daher vermute ich sie als Nachfolger der EFRX Reihe, die ja immer schlechter verfügbar wird, insbesondere die 6TB Variante kostet inkl. Versand schon über 200 Euro, wenn man sie überhaupt noch bekommt. Amazon hat keine mehr und der Händler meines Vertrauens auch nicht.
Die technischen Spezifikationen scheinen sehr ähnlich, bis auf den verdoppelten Cache.
Bzgl. der kleineren EFZX-Modelle könntest Du tatsächlich Recht haben, die scheinen tatsächlich neu zu sein.
Ich glaube aber nicht, dass die technisch viel mit den damaligen EFZX zu tun haben werden.
Die WD-Modellkürzel sagen über die eingesetzten Technologien, Füllgas etc. ja sowieso fast gar nichts aus. Auch hier ist der einzige Unterschied zu anderen Reds wieder der vorletzte Buchstabe, der nur die Cachegröße kodiert:
R = 64 MB (z.B. EFRX)
Z = 128 MB (z.B. EFZX)
A/B = 256 MB (z.B. EFAX, EFBX oder Whites wie EDAZ, EMAZ, ...)
F/G = 512 MB (z.B. EFFX, EFGX oder Whites wie EMFZ, ...)
Mein Verdacht ist, dass die EFRX-Reihe auch deswegen ausläuft, weil sie mit dem kleinen Cache einfach nicht mehr zeitgemäß ist. Ist ja schon seit 2013 so auf dem Markt...
Synology hat die EFRX-Reihe für die 2020er Reihen sogar von den Kompatibilitätslisten geschmissen (bis zu den 2018ern NAS Systemen werden sie voll supported), und keiner weiß genau warum. Vielleicht hängt das auch zusammen und WD will als Mindeststandard bei den NAS-Platten jetzt 128MB garantieren?
Ich könnte mir gut vorstellen, dass sie die Produktionslinie der EFRX, die sie ja notgedrungen nach dem SMR-Debakel wieder auf größere Stückzahlen hochgefahren haben, jetzt ohne allzu große Änderungen auf 128 MB-Cache umgestellt haben. Bis auf die Firmware ist der Rest dann ggf. einfach von der EFRX-Reihe übernommen? Wie gesagt - mit der Helium-EFZX aus 2016/17 würde ich da eher keine größere Verwandschaft erwarten...
Hm, die 220j kam ja recht früh letztes Jahr raus. Bei der erst im Herbst veröffentlichten ds220+ und den anderen größeren ist EFRX durchweg rausgeflogen ...
