News Iron Wolf Pro und Exos M: Seagate bringt 30-TB-HDDs mit HAMR in den Einzelhandel

[kieleich]

Ein RAID Rebuild nach Austausch einer defekten Platte braucht ewig und wehe dabei sterben dann weitere Platten. Ich habe aktuell 24 TB und da braucht es schon 36 Stunden.

Das Problem ist dass Festplatten ihre Fehler gern verstecken, und du ohne Log Monitoring, regelmäßige Test, die Fehler erst Wochen Monate Jahre Später überhaupt erst bemerkst. Diese lange Zeit zum Fehler überhaupt bemerken, das ist das kritische Zeitfenster, nicht die 2-3-4 Tage Rebuild.

Sehr unwahrscheinlich das Platten gleichzeitig sterben aber sehr wahrscheinlich das Fehler erst beim Rebuild auffallen leider, weils dann plözlich darauf an kommt

 

[seyfhor]

Also meine Fotos und Videos die ich mit mein Kameras erzeuge benötigen aktuell 15TB. Jedes Jahr kommt ungefähr 1TB hinzu. 😁

Das waren noch Zeiten als nur Filme mit maximal 36 (?) Bildern pro Film gab.

 

[ThommyDD]

Leider. Das Löschen einer 10 TB Harddisk "DoD konform" dauert eine Woche, wie ich letztens bei 2 solchen Discs schmerzlich feststellen musste. Die Harddisks waren keine SED-Laufwerke.

Festplatten verschlüsseln - das beruhigt auch dann, wenn mal eine ausfällt und recycelt werden muss oder in den Garantieaustausch geht.

 

[Knecht_Ruprecht]

Wie viele Betriebsstunden haben die durchschnittlich runter beim Kauf?

Laut SMART und FARM genau "0". Evt. auch nach zwei Jahren Betrieb noch...

 

[Simonte]

Na das ist doch mal ein Fortschritt, den ich begrüße.
Mal sehen ob man damit ein günstiges Backup basteln kann

 

[Uzer1510]

Das Problem ist dass Festplatten ihre Fehler gern verstecken, und du ohne Log Monitoring, regelmäßige Test, die Fehler erst Wochen Monate Jahre Später überhaupt erst bemerkst. Diese lange Zeit zum Fehler überhaupt bemerken, das ist das kritische Zeitfenster, nicht die 2-3-4 Tage Rebuild.

Sehr unwahrscheinlich das Platten gleichzeitig sterben aber sehr wahrscheinlich das Fehler erst beim Rebuild auffallen leider, weils dann plözlich darauf an kommt

Filesysteme wie ZFS checken zumindest ständig Checksummen egal ob beim Lesen oder Schreiben das zusammen mit SMART und einem gelegentlichen Scrub denke ich ist schon halbwegs ok aber klar ganz sicher ist man nie.

Aber die unentdeckten Fehler sind schon deutlich geringer dann als früher.

 

[Sebbi]

nicht die 2-3-4 Tage Rebuild.

doch genau hier ist ja die krisitsche Phase.

Gerade bei größern Raidverbänden kann es daher durchaus vorkommen, das wenn man eine defekte Platte tauscht, während des Rebuids sich eine weitere verabschiedet, was das Raid, jenachdem wieviele Platten kaputt gehen können, zerstört. Vorallem wenn das Raid schon älter (5 Jahre+) ist und die Festplatten alle das selbe Alter pi mal Daumen haben.
Denn ein Rebuild löst einen massiven Leistungsspike auf 100 % Auslastung über lange Zeit aus, wodurch physiche Schwachstellen, die bei normaler Belastung kein Problem darstellten, auf einmal in Erscheinung treten.

Darum zieht man von älteren Raids auch niemals ein Backup mit voller Geschwindigkeit, sondern begrenzt diese, auch wenn es länger dauert.

Das Problem ist dass Festplatten ihre Fehler gern verstecken, und du ohne Log Monitoring, regelmäßige Test, die Fehler erst Wochen Monate Jahre Später überhaupt erst bemerkst. Diese lange Zeit zum Fehler überhaupt bemerken, das ist das kritische Zeitfenster

Dafür gibt es S.M.A.R.T. , Fehlerkorrekturmassnahmen von der HDD selbst und ggf vom Dateisystem selbst etc etc.
Und auch gerade beim Raid hat man Paritätsdaten, wodurch Defekte an den Daten wieder behoben werden können.

wahrscheinlich das Fehler erst beim Rebuild auffallen leider, weils dann plözlich darauf an kommt

Fehler im Dateisystem? Die sind egal, dafür gibt es die Paritätsdaten etc.
Wie ohen beschrieben sind es die physichen Fehler, wenn Schwachstellen durch den Leistungsspike kaputt gehen, die das Raid zerstören, wenn mehr Festplatten aussteigen als zulässig.

 

[witchdoctor]

Wer braucht denn privat so viel Speicherplatz? Habe aktuell eine 1 TB SSD. Reicht vollkommen. Habe Fotos usw vom Handy in der Cloud. Musik wird gestreamt, Video auch. Früher (vor ca 15-20 Jahren) war das anders, da war ich noch ständig auf der Suche nach mehr (günstigem) Speicher, aber seit ca 10 Jahren hat hier eine Art Sättigung eingesetzt

Von sich selbst nicht immer auf andere schließen. Viele haben eben doch einiges an Fotos und Videos. Zusätzlich gibt es noch Leute, die nicht komplett dem streaming bzw. der Willkür der streaming Anbietern ausgeliefert sein wollen...

 

[Uzer1510]

Bei einem Rebuild werden die HDDs nicht so stark belastet, je nach RAID Aufbau.

Ich habe in meinen Servern z.B. 9 HDDs ein Rebuild heisst

1 HDD schreibt sagen wir mal mit 300 Mbyte/s

8 HDDs liefern Daten = 300/8 ~ 40 Mbytes / sec pro HDD wegen CRC krams etc. Die lesenden HDDs werden jetzt nicht so extrem belastet.

Bei "vielen" HDDs langweilen sich die einzelnen HDDs eigentlich eher weil ja meist das Netzwerk im besten Fall 10 Gbit hat und die Lese und Schreiblast sich ja echt super verteilt.

 

[Sebbi]

@Uzer1510 es geht an der Stelle aber nicht um die Geschwindigkeit, die die Belastung darstellt, sondern darum das viele zufälligen Lesezugriffe auf die vorhandenen Paritätsdaten, die für den Zugriff nötig sind.
Das kann schon bei 5 MB/s zuviel sein, jenachdem wie verstreut die liegen.

 

[Uzer1510]

Das aber bei modernene Filesystemen doch auch nicht so schlimm mehr - ZFS macht doch z.B. best fit - also keine Fragmentierung und mit speculative read ahead cache ist man doch dann auch oft gut dabei.

RAID und Filesystem in einem bringt schon inzwischen grosse Vorteile.

Gerade wenn man sich ältere gebrauchte HW holt für seinen Heimserver hat man doch meist "Monster" was RAM und CO angeht für ein Appel und Ei Kosten und inzwischen das sogar bei moderatem Stromverbrauch.

 

[RedPanda05]

Wer braucht denn privat so viel Speicherplatz?

Du fragst im falschen Forum. Ein nicht kleiner Teil hier ist entweder ein digitaler Messie und hebt jede .txt auf, die nur kurz als Notizblock missbraucht wurde oder ein Pirat und macht mit seiner privaten Sammlung kleinen Streaming Anbietern Konkurrenz.

 

[gaym0r]

Leider. Das Löschen einer 10 TB Harddisk "DoD konform" dauert eine Woche

Wer zwingt dich denn dazu? Einmaliges Nullen reicht ja vollkommen aus.

 

[kieleich]

RAID rebuild ist linear, zufällige zugriffe / seeks gibt es hier nicht. Natürlich vorausgesetzt es ist sonst idle, was im Heimanwender NAS ja oft die Regel ist. Die "hohe Last" ist da herbei fantasiert und von "Backups langsam machen" hab ich noch nie was gehört, fällt unter Esoterik. letzten endes sind festplatten dazu da 24/7 zu brennen, machen sie in servern auch (natürlich auch paar Lüfter) und geht trotzdem jahrelang gut so.

Ich kenn das eigentlich seit ich mit PCs arbeite mit jeder neuen Festplatten generation geht es wieder los. "Oh Gott 1 Terabyte ist ja viel zu groß für RAID" ja in der frühen Zeit waren das auch noch Sprünge 800MB -> 80GB -> TB

Effektiv ist nie was passiert oder nicht mehr oder weniger als sonst. Wer kein Backup hat der hat halt mal Pech beim Rebuild und dann wird Schuld überall gesucht und die aufeinanderfolgende Seriennummer verantwortlich gemacht obwohls damit nichts zu tun hat

im EDV wird genauso viel geschwurbelt wie anderswo

 

[Sebbi]

@Uzer1510
Den Rebulid macht aber nicht das Dateisystem, sondern der Raidcontoller (egal ob Software oder Hardware Raid). Das Dateisystem ist bei einen Rebuild uninteressant, da das Raidsystem selbst den Rebuild durchführt

@kieleich

Dann sag doch mal, warum dann bei Rebuilds ab und zu weitere Festplatten sich aus dem Raidverbund verabschieden, wenn es nicht an der Last liegt ....

 

[plami]

@MichaG Stimmt die Angabe, dass die IronWolf RV-Sensoren hat und die Exos nicht? Das würde ich doch normalerweise andersherum erwarten!?

 

[Uzer1510]

@Uzer1510
Den Rebulid macht aber nicht das Dateisystem, sondern der Raidcontoller (egal ob Software oder Hardware Raid). Das Dateisystem ist bei einen Rebuild uninteressant, da das Raidsystem selbst den Rebuild durchführt

Das gilt aber nicht mehr für moderne RAID Systeme wie ZFS / BRTFS und Co

Dort gibt es keine Trennung Raid und Filesystem mehr beide sind miteinander verbunden, das der Reisenvorteil - nicht nur beim Rebuild auch beim Caching etc. dass der RAID-Teil genau weiss wie es vom Filesystem genutzt wird.

ZFS und BTRFs etc machen den Rebuild nur über tatsächlich belegte Daten.

Hardware Raid ist vor allem deshalb seit ~ 15 Jahren halt nur noch 2. Wahl ( maximal 2. Wahl )

 

[Stagefire85]

Wer braucht denn privat so viel Speicherplatz?

Ein Satz der bei jeder Vorstellung einer neuen HDD kommt.
Immer, garantiert seit 30 Jahren!

 

[kieleich]

ZFS und BTRFs etc machen den Rebuild nur über belegte Daten.

was ein Vorteil ist, wenn wenig belegt ist. wenns voll ist... dann dauert es länger, als die lineare Variante. Dateibasiert gibts wieder Seeks und die brauchen Zeit

Trotzdem kein Problem da es letztendlich nicht so wichtig ist wie lange es dauert

Und das könnte man natürlich auch bei block basiertem RAID so machen! Mit TRIM kann jedes Dateisystem durchgeben was frei ist. Aber das ist natürlich, zumindest beim Linux md raid, nie implementiert worden

Ist auch das Problem was HW RAID Controller haben - man könnte die Technik weiter entwickeln und an moderne Gegebenheiten anpassen. Macht halt einfach nur niemand. Ist alles so ein wenig, in der Zeit stehen geblieben, nach dem Motto "gut genug so" oder "kauft eh keiner mehr"

 

[Uzer1510]

Das fällt aber wegen speculative read ahead Cache doch minimalst ins Gewicht. Das liest ja die Infos als Block ein. Und wie gesagt das Filesystem verhindert sowieso Fragmentierung (solange man ~ unter 90% bleibt)

Nun das Filesystem kann zwar angeben per TRIM welche Blöcke es freigibt aber der HW Controller müsste ja dann mitloggen welche Blöcke das FS danach wieder neu belegt.

Denn ein mit TRIM freigegebener Block kann ja 1 Sekunde später bereits wieder durch das FS mit neuen Daten beschrieben werden.

Der HW Controller müsste halt dann Riesenlisten mitführen was belegt und was frei ist.