"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

"Taranis" RAID-6 Array: 54.5TB (War: "Helios" RAID-6: 5.45TB + Update auf ~11TB)

GrandAdmiralThrawn 30.05.2007 - 21:29 37934 202 Thread rating
Posts

sk/\r

i never asked for this
Avatar
Registered: Dec 2002
Location: oö
Posts: 10585
Zitat von GrandAdmiralThrawn
OK!!!

Ich möchte hiermit ankündigen, daß ich der Allergeilste auf dem Planeten bin!!!11

Ich steh so auf, und denk mir, jo, ich hol mir ein Bier! Stolper ich ned übers Stromkabel am Boden, voll auf die Schnauze. Dreh ich mich so um und seh... 50% vom RAID haben irgendwie KEINE Elektrizität mehr! Stecker rausgerissen.. awhwhuawuah... soviel zum dedizierten PSU...

Zum Schaden auch noch die eigene Blödheit! Das brauchst! :bash:

Der Storage Admin Pr0! :rolleyes:

mmd! :D

Roadrunner

Floating on Water
Avatar
Registered: Mar 2002
Location: /home/tv
Posts: 868
Also das mit dem Bier holen versteh ich voll,
das mit dem drüberstolpern übers Kabel noch mehr, rangiert in der Liga der absoluten Klassiker!! ;)
Und dass du einen Areca Controller hast find ich sowieso sexy,
die sind einfach der burner.
Va der Support von denen is geil, bis auf die Zeitverschiebung :p
Durch deren Hilfe bin ich damals bei meinen 1220er draufgekommen, dass ich zwar grundsätzlich genug Watt beim PSU hatte, aber der staggered spinup zu kurz gesetzt war und ich deshalb immer wiedermal ein degraded RAID hatte.

Ich wünsch dir jedenfalls viel Glück mit deiner Neuanschaffung, St0rage_Pr0n vom feinsten,
und zum Schluss noch ein fettes thumbsup dafür, dass du dir wirklich Zeit nimmst, und dich tief in datasheets vergräbst um das optimum rauszuholen, ist mir bei dir in den letzten Jahren schon aufgefallen! ;)

greetz,
Mario

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
So, der Rebuild ist durch, wonach er jetzt meint, der Array wäre fertig. Leuchtet mir zwar nicht ein, nachdem das Init nicht Mal durchgelaufen ist, aber wurscht. Init wird eh überbewertet!

Hier Mal HDTune und HDTune Pro auf etwas, das so durchaus der fertige Array sein könnte (weiter unten gibt's Truecrypt), das Standardergebnis kommt dann auch in den HDTune Benchmarkthread.

Es handelt sich wieder um RAID-6, 64kiB Stripe Blockgröße wie auch zuvor schon.

Von links nach rechts die Blockgrößen: 4kiB, 64kiB (HDTune Standard) und 1MiB Reads:

click to enlarge click to enlarge click to enlarge

4k ist wie gewohnt "langsam", bei 64k sehen wir seltsame - aber 100% reproduzierbare - Schwankungen in einem bestimmten Bereich des Arrays, und bei 1M geht's richtig rund: Bei einer Blockgröße die breiter als der Stripe selbst ist, scheint die Einstellung "Read and Discard Parity" erstmals das zu tun was sie soll: Sequentielle Zugriffe beschleunigen! Hier verbrennen die Hitachis auch erstmals die Cheetahs mit einer recht konstanten Durchsatzleistung von 1.8GiB/s! Satt, wenn man bedenkt, das mit linearer Skalierung der Disks bei ca. 2GiB/s Ende wäre! Der Array performed hier also wirklich nahe am physikalischen Maximum der Disks. Das 64kiB Ergebnis hingegen ist dank seiner reduzierten Stabilität eher unter den Cheetahs einzuordnen.

Ok, kommen wir zu den Writes. Auch hier hab's Schwankungen, dieses Mal aber interessanterweise bei den höheren Blockgrößen, wohingegen 64k vollkommen stabil war. Auch das ist genau so 100% reproduzierbar. Wie dem auch sei..

Von links nach rechts die Blockgrößen: 64kiB, 512kiB (HDTune Pro Standard) und 1MiB Writes:

click to enlarge click to enlarge click to enlarge

64k ist komplett stabil, bei den großen Blöcken sehen wir gegen Ende des Blockdevices starke Schwankungen. Alle Writes liegen im Schnitt über 1GiB/s wenn auch knapp was die 64k angeht. Mit einer satten Blockgröße von 1MiB schreibt der Array im Schnitt mit 1.5GiB/s.

Und zum vorläufigen Abschluß noch eine neue GPT Partition eingerichtet - aligned nach bestem Wissen - und mich an Truecrypt versucht. Das ist direkt SO schnell, daß man ein Full Encrypt durchrennen lassen kann, auch bei dieser Arraygröße (sofern er ned wieder crashed dabei), das hier "sollten" 512b Writes sein:

127k6000_raid6_tc-format_209225.png
Keyprints wurden natürlich zensiert. Nach etwa einer halben Stunde Laufen Lassen pendelt sich die Sache bei ~725MiB/s ein. Das reicht natürlich nicht an die theoretischen Transferraten heran, liegt aber in einem gesund hohen Bereich würde ich sagen.

Nur eines ist jetzt trotz AES-NI Beschleunigung etwas spannend... Bei derart hohen Transferraten würgt's der CPU nämlich einfach trotzdem eine rein. Zwar schafft der Xeon X5690 irgendwas zwischen 4-5GiB/s im TC Bench mit Hardwarebeschleunigung, aber bei mehr als 700MiB/s wird das dann halt natürlich trotzdem meß- und spürbar:

127k6000_raid6_tc-format_taskmgr_209226.png
Der Preis der Kryptographie, hier in Echtzeit bezahlt für: AES256-XTS.

Tarari Trara, Trarumsassa.
Bearbeitet von GrandAdmiralThrawn am 21.11.2015, 11:38

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
Zitat
Aber so wie mein Platzangebot ist, hatte ich Angst daß mich der Rechner dann permanent anbläst, daher hab ich das sein lassen.
Versteh ich 100%ig. Anblasen lassen geht garnicht. :D

Zitat
St0rage_Pr0n vom feinsten
Jop. :) Bis einer so etwas mit 12Stk 2TB SDDs aufzieht. :D OK, weniger Platz aber imho mehr Pr0n. ;)

Zitat
Hier verbrennen die Hitachis auch erstmals die Cheetahs mit einer recht konstanten Durchsatzleistung von 1.8GiB/s!
:p Oarg! Jetzt fehlt noch die 2x 10GBase Anbindung damit das (theoretisch) auch übers Netz flitzen könnte. :D

Zitat
Zwar schafft der Xeon X5690 irgendwas zwischen 4-5GiB/s im TC Bench mit Hardwarebeschleunigung, aber bei mehr als 700MiB/s wird das dann halt natürlich trotzdem meß- und spürbar:
18% CPU Auslastung.. nehmen wir an davon sind 15% TC bei 700MiB/s, dann ergäbe das 4,6GiB/s bei theoret. 100%. Paßt eh genau.

Zitat
Tarari Trara, Trarumsassa.
Auf alle Fälle. Jetzt noch eine USV reinhängen, die Stromkabel verstauen und sichern sowie den Bierzugang optmieren, und die Sache schnurrt dahin. ;) :D
Bearbeitet von Valera am 21.11.2015, 20:32

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
USV hat nur der Server, den Rechner hier sicher ich so ned ab (zu teuer, ******* Batts immer), daher "billig" per FBM, Rest soll chkdsk machen, wenns wirklich kracht, Hauptsache FS is konsistent. ;)

LAN brauch ich ned. Das ist kein NAS. Das ist eine Workstation+DAS. Ich brauch den Speed auch wirklich lokal. Ned daß teamed 10GbE lahm wären, aber es macht ned wirklich Sinn das in eine extra Maschine auszulagern.. Ich will die Workstation sowieso 24/7, bin das schon so gewohnt, daß ich's auf der Arbeit auch durchrennen lasse.

Ich schalt keine Rechner ein! Ich schalte nur Bildschirme ein! ;)

Capsicum_Annuum

Bloody Newbie
Registered: Nov 2015
Location: fc
Posts: 44
Zitat von GrandAdmiralThrawn
Ok ok, werft mir ruhig Dramatisierung vor. ;)

Hier neben mir liegt gerade ein Stapel von 8 Stück Hitachi 7K1000 Disks.
Die verd*mmten Kabel!

werden dann bei RAID-6 in etwa 5.45TB nutzbaren Speichers ausmachen.

Hättest mal bis ende 2014 gewartet:
http://geizhals.at/seagate-archive-...27.html?hloc=at

:D

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
Ich verstehe nicht ganz... Das mit den 7K1000 war der erste 3ware Array, das is jetzt 8 Jahre her.. In 2007 wußte noch kein Mensch, daß es irgendwann Archiv-HDDs auf SMR Basis geben würde.

Außerdem steckt man sowas doch ned in ein RAID... also ich würd's nicht machen. Und ich bin ja jetzt 2 Arrays weiter..

Oder ich check grad irgendwas ned? :confused:

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
Ich checks a ned. Die SMR Archive Platte tät ich nicht in ein RAID hängen, zumindest nicht in ein konventionelles/ leistungsorientiertes Hardware RAID. Das paßt vorne und hinten nicht zusammen. Bei einem Software Verbund das als Archiv verwendet wird lasse ichs mir einreden aber da? Nö. Wäre mir zu lahm und unsicher.

8 Jahre alte Hardware mit dem was heute erhältlich/leistbar ist zu vergleichen ist aber grundsätzlich lustig. Vor ca 8 Jahren habe ich meinen 8x300GB RAID5 Server eingemottet. Da waren nicht mal 2TB Platz drauf. Das Volumen liegt heute in der Klaut. :D :D
Bearbeitet von Valera am 22.11.2015, 22:05

Capsicum_Annuum

Bloody Newbie
Registered: Nov 2015
Location: fc
Posts: 44
Zitat von GrandAdmiralThrawn
Oder ich check grad irgendwas ned? :confused:

Das war eine Anspielung das sich doch was am HDD Markt getan hat,
SMR ist auch nicht sooo lahm aufjedenfall schneller als meine ST31000520AS
Bearbeitet von Capsicum_Annuum am 23.11.2015, 07:03

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
Das Problem is, daß ich immer noch keine Benchmarks einer mind. einmal komplett vollgeschriebenen SMR Disk gesehen habe.

Sprich: Ich weiß nicht wie schnell die noch ist, sobald's mit Read-Modify-Write losgeht. Solangst noch direkt schreiben kannst, isses ja kein Thema, wie bei SSDs auch (vor'm TRIM Zeitalter).

Ich hab ca. gleich viel Schreiblast wie Leselast, von daher ist das nicht so unproblematisch. Zudem wollte ich natürlich die <1 UREs in 10¹⁵ Bitreads Fehlerrate auch schwarz auf weiß haben, plus 5 Jahre Garantie. Andere Dinge wie Vibrationskompensation, SAS usw. sind dann Boni.

Aber jo, der HDD Markt is alles andere als tot. Das hat sich genau so entwickelt, wie ich es mir seit der Intel X25 G1 schon gedacht habe: SSDs für OS, Programme usw., und HDDs für lineare Loads und Cold Data. Weil am Anfang ja alle gleich dabei waren die HDD in den nächsten 5 Jahren totzusagen. ;)

Edit: Soda, Truecrypt ist durch. Hat sich noch etwas zaht, weil neben die x264 Pressen CPU weggefuttert haben. Jetzt ist Mal rsync zu Werke gegangen.. seltsam nur: Irgendwie will rsync ned schneller als 80MB/s fahren... Obwohl beide Arrays (Quelle wie Ziel) viel schneller wären...

Edit 2: Argl, das is auch die CPU Last... Dabei rennt x264 eh mit niedrigster Prio... Najo, mit rsync @ High gehts wenigstens über 100. Wenn ich alles andere pausiere aber auch nicht höher als 120MB/s.. Quelle vielleicht schon so schlimm fragmentiert.

Edit 3: Äh?! Mal nachgesehen. Ich denke der rsync Total Progress Meter (--progress --info-progress2) ist komplett broken, oder ich lese ihn falsch? Der meint er habe 220GB kopiert, dabei liegen schon 600GB am neuen RAID drüben mittlerweile, häh?!
Bearbeitet von GrandAdmiralThrawn am 23.11.2015, 12:14

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
Zitat
<1 UREs in 10¹⁵ Bitreads Fehlerrate
Auch nur eine Zehnerpotenz besser als Consumerplatten. Damit hast dann nicht einen statistischen Error in 12,5TB sondern einen in 125TB. :p Das bedeutet bei deiner Speichergröße fast das gleiche wie bei anderen mit 10^14 :D :D
Ich setze daher lieber auf ein redundantes Filesystem mit Datenintegritätsprüfung und -wiederherstellung. Aber das Thema hatten wir schon.
Zitat
Ich denke der rsync Total Progress Meter (--progress --info-progress2) ist komplett broken
Ich weiß nicht ob das komplett broken ist aber rsync hat bei mir noch nie irgendetwas reales angezeigt. Ähnlich wie der Kopierdialog bei Windoof. :p

Zitat
Weil am Anfang ja alle gleich dabei waren die HDD in den nächsten 5 Jahren totzusagen.
Jo, das waren die Leute die jeden Hype hinterherjagen und net arbeiten sondern nur wischen. ;) Aber mittlerweile ist das Ende der HDD tatsächlich absehbar. Die Packungsdichte der SSD ist viel geringer, der Stromverbrauch hält sich auch in Grenzen, nur der Preis pro TB ist noch jenseitig. Wenn sich da nichts revolutionäres mehr tut wird uns die HDD noch ein paar Jahre begleiten aber dann wars das.
Bearbeitet von Valera am 23.11.2015, 20:16

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
125 statt 12.5 ist jede Menge, du mußt das ja mehr oder minder pro 6TB Disk rechnen, nicht auf den ganzen Array. Wenn Block #3 bei Disk 1 und Block #4 bei Disk 2 im Rebuild hin ist, dann macht das ja nichts. Nur zwei Blöcke auf einmal dürfen im Single Disk Rebuild ned URE'n (um das Mal als Verb zu mißbrauchen) in RAID-6, sonst knallts im strikten Rebuild.

Aber so ist die niedrigere Wahrscheinlichkeit in dieser Dimension wohl ein sehr guter Schutz, solange die Angabe stimmt.

Wie niedrig ist da die Wahrscheinlichkeit, daß zwei UREs im selben Stripe Band daherkommen...

@rsync: Daß er bei der verbleibenden Kopierdauer nur Schas anzeigt, leuchtet mir eh ein. Aber daß er auch den Durchsatz in MB/s und die bereits kopierte Datenmenge falsch anzeigt is schon etwas wirr. Ich kopier jetzt noch zusätzlich mit --no-inc-recursive, damit die komplette Datenmenge vorm Kopiervorgang erfaßt ist und laß es so rennen. Auf FreeBSD grade getestet, und dort hauts scheints sauber hin damit. Mal schaun...

Kopieren an sich tut er offenbar sauber, bisherige Stichproben sagen: Alles intakt. Am Schluß kommt eh noch ein volles binary diff.

Edit: Mit --no-inc-recursive scheint er saubere Werte zu liefern...

Edit 2: So, ich war ja besorgt darüber was der Areca machen würde, wenn in einem 2-Disk Rebuild ein URE/badblock auf einer anderen Disk daherkommt. Oder von mir aus einer im Single-Disk RAID-5 Rebuild. Daher Mal wieder den Areca Support kontaktiert.

Zudem habe auch auch gefragt, was er im eigentlich korrigierbaren Fall tut, also wenn bei RAID-6 ein URE/badblock im Single Disk Rebuild auftritt.

Mr. Kevin Wang klärte das auf:

Zitat
Kevin Wang vom Areca Support:

  1. if another disk has a bad block during a single disk failure + rebuild, controller will correct that on the fly.
  2. controller will ignore bad blocks and just continuing the rebuild when an URE/bad block is encountered during a 2-disk rebuild.

and both 1 and 2 are firmware internal feature, you have no option to configure it.
Sehr spannend. Der Areca ist also default nicht strikt, und wagt es, die Datenintegrität für einen einzelnen Stripe Block zu risikieren, um nicht den kompletten Array failen zu müssen, wenn ihm im Rebuildfall die Redundanz für sowas ausgeht. Für mich passt das!

Sollte man für Systeme auf denen absolute Datenintegrität ein MUSS ist aber evtl. im Hinterkopf behalten, da dieses Verhalten nicht konfigurierbar ist, wie bei 3ware.
Bearbeitet von GrandAdmiralThrawn am 24.11.2015, 10:53

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
So, ich monologiere Mal weiter, mittlerweile ist rsync durch, oder zumindest so "fast". In einigen (sehr) wenigen Fällen ist es offenbar zu einer Art Race Condition gekommen, und zwar zwischen dem Avast AV und rsync.

rsync kopiert Daten ja in eine temporäre Zieldatei à la ".datei.bin.ky354" oder so, und benennt nach Abschluß des Vorganges z.B. auf "datei.bin" um. Nun hat Avast aber offenbar einen Lock auf die Datei offen, weil er's ja scannt. Released der AV den Lock ein wenig zu spät, schlägt rsyncs Rename fehl, und die intakte temporäre Datei bleibt so wie sie ist liegen. Najo, dafür gibt's ein Logfile, und die Vorfälle sind extrem rar, aber dennoch lästig.

Avast, der Idiot! :rolleyes:

Mal schaun ob die Integritätsprüfung noch vor'm/am Wochenende fertig wird...
Bearbeitet von GrandAdmiralThrawn am 27.11.2015, 11:19

COLOSSUS

Administrator
Frickler
Avatar
Registered: Dec 2000
Location: ~
Posts: 11892
Mandatory Locking bei jedem open() ist halt einfach scheisze.

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3682
So, diff ist durch, das Logfile zeigt nicht weiter kritisches, der AV hat auch nur einige wenige Files gestoppt, besonders gierig war er scheints bei *.exe. :rolleyes:

Na wie auch immer, Laufwerksbuchstaben sind switched, jetzt noch den inzwischen am alten - jetzt "offline" - Array neu hinzugekommenen Schund rübersyncen, dann passts.

Damit fehlt dann nur noch ein Schritt: Shutdown, den alten Array rausreißen, alles sauber anschließen, endlich den Deckel drauf und fertig. Das wird seit langem das erste Mainsys bei dem ich endlich Mal die Seitenwand zumachen kann ohne daß alles im Inneren verbrennt. :rolleyes:

Bei der Gelegenheit mach ich dann auch noch Fotos von den Disks.

Edit: Bissl was is ja noch frei. ;)

volume-properties-filled_209806.png
Das kleine blaue Dreieck wird noch länger was zu fressen haben...

Edit 2: Und noch so'n paar alte Windows Benches:

ATTO 2.47 (der 3.05er rennt eh, aber benched irgendwie nix bei mir?!):
atto-2-47_209816.png

HDTach Short Zones (8M):
hdtach-3-0-4-0_short_209812.png

HDTach Long Zones (32M):
hdtach-3-0-4-0_long_209813.png

Everest Read Suite:
everest-readsuite_209814.png

Aida64 Read Suite:
aida64-readsuite_209815.png
Bearbeitet von GrandAdmiralThrawn am 28.11.2015, 16:04
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz