8 Terabyte Festplatten - Seite 7
URL: https://www.overclockers.at/storage-memory/8-terabyte-festplatten_241481/page_7 - zur Vollversion wechseln!
GrandAdmiralThrawn schrieb am 02.02.2015 um 14:16
Rebuild oder Restore? Ich weiß nicht ob man sich Zeit spart, wenn man von einem Backup wiederherzustellen hat bei einem Ausfall, oder ob man rebuilded. Wie gesagt, um den URE Fall als Problem auszuschließen, muß eben die Storage Controller Firmware entsprechend konfiguriert sein.
Ausfallen werdens so oder so, und dann ist SMR immer langsam, wennst Wiederherstellung brauchst.
Oder meinst du replizierst gleich auf mehrere Storage Appliances, weils so schön wenig kostet mit der Disk? Und solange nur eine Box online bleibt passts eh?
Edit: Bei genauerer Betrachtung von SMR fällt mir auf, daß ein Restore wohl gar nicht Mal lahm sein müßte, weil man die Disk ja linear beschreiben kann, von Anfang bis Ende... Ohne R-M-W..
Valera schrieb am 02.02.2015 um 21:24
Ob bei der SMR Technologie Rebuild oder Restore "besser" ist, ist zu diesem Zeitpunkt wohl pure Spekulation - oder hat schon jemand SMR Disks im Einsatz?
Imho hängt das davon ab, ob das System offline gehen kann oder nicht. Bei mir im privaten Bereich ist es (derzeit noch) egal ob das System offline ist. Ob das in Zukunft wenn die Kinder größer sind, dann auch noch so ist sei mal dahingestellt.. 
Egal, ich denke wenn man so ein Array hat, dann muß man das selber entscheiden und ob die Disks dann SMR whatever sind ist dann eher nebensächlich weil so oder so wird ein neuer Datenträger (mehr oder weniger) linear beschrieben.
Raid: Naja, das macht schon Sinn wenn man große Datenträger oder Redundanz benötigt. Aber klar, ein Raidz2 (Raid6) Array mit der 8TB HDD in der klassischen Variante 4+2 hat 29TB. Übers Gigabit Netzwerk mit sagen wir 80MB/sek bei einer maximalen Belegung von 80% (~23TB) würde ein kompletter Restore > 29.000 sek ~ 4.900min ~ 81 Std ~3,5 Tage benötigen. Eh human.
Cobase schrieb am 02.02.2015 um 21:47
Raid: Naja, das macht schon Sinn wenn man große Datenträger oder Redundanz benötigt. Aber klar, ein Raidz2 (Raid6) Array mit der 8TB HDD in der klassischen Variante 4+2 hat 29TB. Übers Gigabit Netzwerk mit sagen wir 80MB/sek bei einer maximalen Belegung von 80% (~23TB) würde ein kompletter Restore > 29.000 sek ~ 4.900min ~ 81 Std ~3,5 Tage benötigen. Eh human.
Wer sich 8TB-Festplatten in einem Raid6-Verbund leisten kann, kann sich auch ein NAS mit 10GBase-Anbindung leisten.
Valera schrieb am 02.02.2015 um 22:17
Wer sich 8TB-Festplatten in einem Raid6-Verbund leisten kann, kann sich auch ein NAS mit 10GBase-Anbindung leisten.
Glaub nicht, dass die Platten bei durchschnittlichen Daten viel mehr als 80MB/sek machen. Egal ob 1 Gbit, xmal Gigabit oder 10GBit. Schau dir die Rebuild Times in den Reviews an, wenn Enterprise Platten ein Raid mit Parity wiederherstellen. Da bist ca. in der Kategorie. Intern. Bei einem Restore mit Hardware die sich ein Consumer leisten kann - also zB die angesprochenen SMR 8TB Platten - geht imho nicht (viel) mehr. Wenn die wie die zB WD Red performt kannst 1Gbit nicht ausreizen.
Klar, wenn es sich nur um große Dateien handelt wie zB Video dann schaut das gaaanz anders aus.
NAS mit 10GBit >2000 Euronen (mit Hardware die die Geschwindigkeit auch unterstützt) ohne Platten.
Ein Haswell Xeon E3-1220V3 Server mit C2xx Chipsatz, LSI SAS2308, 32 GB ECC Ram, 40GB SSD ca 900,- + 350,- für die 10Gbit Nic = 1250,-.
6x Seagate 8TB = 1.560,-
Also bei den Kosten ist man bei der 10GBit NIc bei ca +15% Aber: Switch und Clients müssen ebenso mit 10GBit versorgt werden. Das geht ins Geld. Das kann/will sich einer, der auf diese Platten wartet, imho eher nicht leisten weil sonst hätte er Enterprise Hardware verbaut.
Ich weiß wirklich nicht ob sich 10GBit mit den Platten auszahlt. Werden wir alles sehen. Ich warte auf die early adopters. Bitte gleich testen und posten.
edit: 2x wirklich in einem Satz geht einmal wirklich gar nicht. Wirklich.
spunz schrieb am 03.02.2015 um 08:31
Raid: Naja, das macht schon Sinn wenn man große Datenträger oder Redundanz benötigt. Aber klar, ein Raidz2 (Raid6) Array mit der 8TB HDD in der klassischen Variante 4+2 hat 29TB. Übers Gigabit Netzwerk mit sagen wir 80MB/sek bei einer maximalen Belegung von 80% (~23TB) würde ein kompletter Restore > 29.000 sek ~ 4.900min ~ 81 Std ~3,5 Tage benötigen. Eh human.
Im Firmenumfeld stellt man einfach eine zweite/dritte/... Box hin und hofft das es nie alle Spiegel gleichzeitig zerlegt. Privat wird es wohl kein großes Problem sein wenn der Restore 2-3 Tage dauert.
spunz schrieb am 03.02.2015 um 08:43
Mich verwirrte das ehrlich gesagt auch ein wenig. Einerseits hieß es immer die Disk sei für Kaltdaten gedacht.. andererseits Dauerbetriebeignung?
mit Dauerbetrieb ist eher regelmässiger I/O gemeint, nicht der Leerlauf der Platten.
GrandAdmiralThrawn schrieb am 03.02.2015 um 10:19
Hmm, seh schon, die Enterprise Disks sind mit der doppelt so hohen Anzahl an Load/Unload Cycles spezifiziert. Aber bei der 8TB wirst tendenziell viel mehr Seeks und Rewrites haben wegen SMR, also statistisch mehr Schreibvorgänge pro zu schreibendem Sektor.
Was mich ECHT Mal interessieren würde: Wie breit sind die SMR Bänder bei den Seagate Disks? Dazu find ich nirgendwo Infos. Nur Aussagen a la "die Breite ist an das Aufgabengebiet der jeweiligen Platte angepaßt". Jo schön. Nur ich hätte gerne Zahlen.
Valera schrieb am 05.02.2015 um 23:27
Im Firmenumfeld stellt man einfach eine zweite/dritte/... Box hin und hofft das es nie alle Spiegel gleichzeitig zerlegt. Privat wird es wohl kein großes Problem sein wenn der Restore 2-3 Tage dauert.
Jo eh. Steht eh in meinen Post(s).
Was mich ECHT Mal interessieren würde: Wie breit sind die SMR Bänder bei den Seagate Disks?
Ich weiß nicht was mich noch weniger interessiert als die Innereien der Platten. Vielleicht Socken ordnen? Mich interessiert in erster Linie die Zuverlässigkeit, dann die Zuverlässigkeit, die Zuverlässigkeit, ... , Preis und Geschwindigkeit.
Ich weiß nicht wieso es eine vorgehaltene Waffe braucht, damit du zu SMR Disks greifst? Warten wir doch die Testergebnisse der early adopters ab. DAs heißt ich warte auf deine kompetenten und ausführlichen Tests der SMR Disks unter Windows XP 64bit - in etwa Mitte dieses Jahres.
davebastard schrieb am 06.02.2015 um 01:05
nicht wieso es eine vorgehaltene Waffe braucht, damit du zu SMR Disks greifst? Warten wir doch die Testergebnisse der early adopters ab. DAs heißt ich warte auf deine kompetenten und ausführlichen Tests der SMR Disks unter Windows XP 64bit - in etwa Mitte dieses Jahres.
GrandAdmiralThrawn schrieb am 06.02.2015 um 08:22
Ganz einfach: Neugierde. Ich will genau WISSEN was in der Platte wirklich vorgeht. Klar kann man sich auch einfach Random Write Benchmarks auf einer bereits fast voll beschriebenen Disk ansehen, aber ich will nicht nur die Ergebnisse kennen, sondern auch die exakte Ursache, und zwar bis ins letzte von mir verstehbare Detail.
Habe mir zu SMR auch schon einige wissenschaftliche Papers durchgelesen, weil ich die Konsequenzen korrekt verstehen will, und super schaut das ned aus.
Mit "Socken" würde ich Interesse an technologischen Systemen und Vorgängen aber nicht vergleichen. Ich mein, ist das jetzt oc.at hier, oder sind wir bei den Sockenklaubern unterwegs oder was?! 
SMR erachte ich jedenfalls als den falschen Weg, speziell weil ich eine 50:50 Last zwischen R/W habe. Sprich, ich schreibe ca. so viel wie ich lese, und beide Vorgänge sollen ausgeglichen schnell sein. SMR ist für mich einfach ein billiger Trick mit viel zu großen Nachteilen, architektonisch schon.
Wie eine SSD ohne TRIM oder GC quasi.
In der Praxis gehts darum, große Datenmengen (50-200GB) auf einen Satz zu lesen, zu teilen und wieder aufs selbe Medium rauszuschreiben. d.h. ich brauche einen ausgeglichenen Speed zwischen R und W.
Ich würde lieber HAMR/MAMR oder bit-patterned Media sehen, aber die Technologie ist halt ungleich aufwendiger und teurer, also schießens zuerst das billigstmögliche raus.
Bin schon gespannt wann wir die ersten SMR SAS Disks mit einer URE Rate <1 in 10^15 sehen. Solange das I/O Profil deutlich mehr auf der Lesen-Seite liegt ok, ist aber bei mir nicht so.
Eine SMR würd ich also nicht Mal geschenkt wollen (wenn ned der Wiederverkaufswert wär).
Edit: Die Zuverlässigkeit, natürlich ein wichtiger Punkt. Die glaube ich durch den Griff zu SAS Disks mit einer Fehlerrate von <1 in 10^15 und 5 Jahren Garantie sicherstellen zu können, falls ich nicht grade arges Pech habe. Ansonsten sind immer noch RAID-6 und die Garantie da, wenn's wirklich sein sollte. Bislang hab ich da viel Glück gehabt, vielleicht geht's ja so weiter.
daisho schrieb am 06.02.2015 um 08:22
Ich weiß nicht was mich noch weniger interessiert als die Innereien der Platten. Vielleicht Socken ordnen? Mich interessiert in erster Linie die Zuverlässigkeit, dann die Zuverlässigkeit, die Zuverlässigkeit, ...
Aber genau das kann dir keiner beantworten und der Hersteller wird lügen wenn es schlecht aussieht. Insofern kann es schon etwas bringen etwas über die Innereien der Platte zu wissen - wenn man sich damit auskennt kann man sicherlich über das eine oder andere eine Mutmaßung anstellen.
Valera schrieb am 06.02.2015 um 22:27
Mein Post war eigentlich als Scherz gedacht, ich hab mir schon erwartet, dass "Socken ordnen" (hier in diesem Forum und überhaupt im Zusammenhang mit GAT) derart anachronistisch ist, dass die Ironie erkannt wird - vielleicht wäre "Unterwasserbügeln" besser gewesen. Aber ich habe einfach zu wenige Smileys gesetzt - Tschuldigung.
Die URE Rate als Zuverlässigkeitsfaktor: Imho ja, was die Datenintegrität betrifft, nein was die Lebensdauer des Materials betriffft. Die URE wird (bzw kann) im wesentlichen durch zusätzliche Fehlerkorrektur erhöht.
Ich würde lieber HAMR/MAMR oder bit-patterned Media sehen,
Ja ich auch. Aber das eine schließt das andere ja nicht aus. Dort wo Kapazität/Preis wichtig ist, sind + ~25% mehr Platz ein starkes Argument.
Wie hier schon mal erwähnt wurde: Bei Verwendung von CoW Filesystemen glaube ich garnicht, dass es einen wesentlichen Performanceverlust gibt.
[edit] Hast du CoW Filesysteme schon auf XP portiert? [/edit]
Insofern kann es schon etwas bringen etwas über die Innereien der Platte zu wissen - wenn man sich damit auskennt kann man sicherlich über das eine oder andere eine Mutmaßung anstellen.
Als Techniker bin ich der letzte der jemanden davon abhält in die techn. Details zu versinken. Aber es interessiert mich was man sich davon verspricht. Außer "so halt". 
DAO schrieb am 07.02.2015 um 13:35
was gabt ihr gegen socken?
ich interessiere mich für die herkunft meiner socken und deren fasertechnologie.
aber zum thema:
wenn ein hersteller werte wissentlich nicht angibt dann hat das einen grund.
meist um etwas zu verbergen.
GrandAdmiralThrawn schrieb am 08.02.2015 um 10:32
Die URE Rate als Zuverlässigkeitsfaktor: Imho ja, was die Datenintegrität betrifft, nein was die Lebensdauer des Materials betriffft. Die URE wird (bzw kann) im wesentlichen durch zusätzliche Fehlerkorrektur erhöht.
Najo klar, es gibt halt keine Kennzahlen für die Lebensdauer der Motoren, Aktuatoren, usw. Aber sonst hast bei der Zuverlässigkeit eh nur die Möglichkeit abzuwarten, bis die Märkte ausreichend durchsetzt sind, um eine Aussage zu treffen. Bei SMR kannst dir noch ca. ausrechnen wieviele Extra Seeks, Reads und Writes du kriegst, um es bei einem bestimmten Storageprofil abschätzen zu können.
Wie hier schon mal erwähnt wurde: Bei Verwendung von CoW Filesystemen glaube ich garnicht, dass es einen wesentlichen Performanceverlust gibt.
[edit] Hast du CoW Filesysteme schon auf XP portiert? [/edit]
Es gibt Grenzen, also abgesehen von Volumenschattenkopien: Nein.
Aber bei CoW ist auch die Frage: Wohin schreibe ich die veränderte Kopie? Wie bei SSDs hab ich auch bei SMR Disks ohne eigenes ATA Kommando keine Ahnung wo wirklich "freie" Bereiche sind. Ich mag auf Dateisystemseite annehmen dürfen, daß ein gewisser Track frei ist, aber ich habe keine Ahnung von SMR Bändern und Track Overlaps. Ich kann kein "Band" adressieren, nur einen Sektor in einem Track.
Bei CoW müßte ich also auch raten wo ich hinschreibe und kann dabei erst wieder ein Band erwischn, wo read-modify-writes passieren. Speziell wenn das Volume recht voll wird. Wird natürlich schneller sein als ohne CoW, aber ganz lösts die Sache auch nicht?
Dazu bräuchte es eine direkte Öffnung der Struktur hin zum Betriebssystem, und eigene Dateisysteme die mit der Struktur direkt arbeiten können. Also Dateisysteme, die Bänder und Sektor-Overlaps direkt sehen. Also brauchst eigene Festplatten, und eigene Dateisysteme, dann kannst RMW-freies CoW garantieren. Sowas wurde in einigen Papers die ich zum Thema gelesen habe vorgeschlagen - für den Einsatz im Cloudbereich.
Als Techniker bin ich der letzte der jemanden davon abhält in die techn. Details zu versinken. Aber es interessiert mich was man sich davon verspricht. Außer "so halt".
Hm. Man kann bessere, fundiertere Entscheidungen treffen und das Wissen an andere weitergeben, damit diese es auch können. Abgesehen davon braucht Neugierde denke ich einfach keine weitere Begründung mehr um als starker Antrieb zu funktionieren. 
wacht schrieb am 08.02.2015 um 11:11
Je mehr ich mich mit irgendeiner Technologie beschaeftig die schon industriell angewandt wird desto mehr wunder ich mich immer dass das Zeug ueberhaupt irgendwie funktioniert und noch mehr das es so robust is
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026