[Sammelthread] Advanced Format - 4kB Sektoren bei HDDs

so, ein paar vorläufige Screens, Daten wie gesagt: LSI 9260-4i, HD204UI, Raid6, Strip Size 265kb, Volume gefüllt mit einigen 50-1000GB großen Zufallsdateien.
HDtune Pro mit Standard- Benchmark Size 64kb, Short Stroke,
LESEN!
Volume leer:
http://extremecomputer.de/read-leer-raid6.PNG
Volume voll:
http://extremecomputer.de/read-voll-64kb-shortraid6.PNG

dann noch ein Full- Scan 64kb:
http://extremecomputer.de/read-voll-64kb-full-raid6.PNG
und Full Scan 8MB:
http://extremecomputer.de/read-voll-8mb-full-raid6.PNG

SCHREIBEN!
via "DummyFileGenerator" ans Ende des vollen Volumes eine 25GB Datei geschrieben:
http://extremecomputer.de/write-25gb-voll-dfg-raid6.PNG
bei leerem Volume war dieser Wert bei ca. 240MB/s, natürlich ein Einbruch, aber ob dieser mit der Sektoren Thematik zu tun hat vermag ich nicht einzuschätzen. Liegt wohl eher am vollen Volume.

Während der ganzen Tests gabs keine Probleme mit aus dem Raid gedroppten Platten usw.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hmm.. beim Raid6 scheint echt der Controller zu limitieren. Geht ja iwie kaum über 200MB/s hinaus. Aber sieht doch soweit i.O. aus. Wenns so bliebe, wärs doch gut... ;)
 
ja, definitiv, denn im Raid 0 gehts über 500MB/s hinaus.
Aber ich finde die Raid 6 Performance ordentlich, bei mir gehts sowieso nur darum die volle Geschwindigkeit für 1Gbit/s Netzwerke zu erreichen.

Naja, werde nun für eine Zeit regelmäßig Daten hin und her schieben und das ganze im Auge behalten. Es wäre natürlich sinnvoll, dabei herauszufinden ob es doch irgentwelche Faktoren gibt die das ganze zum kippen bringen. Andererseits lauten die Berichte von Problemen mit 4k Platten allesamt von "unmittelbaren", also von Anfang an schlechte Performance, droppende Platten usw.
 
Ich werde nun nochmal den Test machen und mir 4 204er holen, werden an einem Areca 1261ml laufen, was soll ich testen?

Ich kann Sie wunderbar gegen mein Raid5 aus 4 203ern antreten lassen, ich denke, dann haben wir direkten Vergleich.
 
wäre super, aber ob mein Testablauf was taugt weiss ich leider nicht. Aber der direkte Vergleich der Übertragunsraten ist sicher auch schon was:)
 
Auf die Tests bin ich auch mal gespannt .. fein mal alles mit HD Tune durchquälen :)
 
Jo, testen testen testen!

@andichen Wieviele HDDs sind das? 3 Stück? Falls ja, ist das in der Regel kein Problem, da du immer bei 4kb Verteilungen landest.

@frank
Auf jeden Fall mal nen 4er RAID5 testen, so dass du 3HDDs Nutzdaten hast. Damit sollten dann keine 4kb Verteilungen auftreten, also genau das, was wir net wollen und dann schauen, was die Performance nach einiger Zeit sagt, wenn du da ordentlich Daten hin und her geschautelt hast. Und sie hoffentlich net aus dem RAID droppen.
 
underclocker2k4 schrieb:
@frank
Auf jeden Fall mal nen 4er RAID5 testen, so dass du 3HDDs Nutzdaten hast. Damit sollten dann keine 4kb Verteilungen auftreten, also genau das, was wir net wollen und dann schauen, was die Performance nach einiger Zeit sagt, wenn du da ordentlich Daten hin und her geschautelt hast. Und sie hoffentlich net aus dem RAID droppen.
Zum Vergrößern anklicken....

Moment...
Die Rechnung Stripesize durch Anzahl der HDDs (ohne Redundanz) geht nur bei Raidlevel ohne Paritätsberechnung auf. Denn dort spielt es keine Rolle.
Bei Raidleveln mit Paritätsberechnung muss der Teil wo die Paritätsdaten liegen mindestens (oder gar exakt) so groß sein, wie der Teil der Nutzdaten auf den anderen HDDs.
Das heist also, mit vier HDDs im Raid 5 würde die Rechnung aufgehen...
Bei drei HDDs im Raid 5 hingegen nicht. Denn dort wäre ein Teil (warscheinlich der Teil der Paritätsdaten) minimal größer, der gelesen werden muss. Beim lesen sollte das weniger die Rolle spielen, denn dort wird nicht mit den Paritätsdaten gehandelt (oder nur selten, bin mir da aber nicht ganz sicher)
Beim schreiben hingegen schon.
Mit vier HDDs wäre also bei einer StripeSize von 64KB pro HDD eine ChuckSize von 16KB zu verzeichnen.
Mit drei HDDs hingegen würe die Aufteilung 21/21/22. Das ganze wird dann durchrotieren, weil die Paritätsdaten ebenso durchrotieren.
Der Schreibvorgang der Paritätsdaten dauert also in jedemfall minimal länger...

Ich meine mich daran zu erinnern, das kann man auch auf gängigen Benches sehen, wo eben ungerade Anzahlen von HDDs in Paritäts-Raidleveln weniger Performanceplus zeigen als gerade Anzahlen von HDDs.

Mit dieser Aufteilung, also drei HDDs und 64KB Stripesize würde man auch der 4KB HDD nicht wirklich einen Gefallen tun.
Wobei halt immer die Frage bleibt, wie viele Daten ließt der Controller wirklich am Stück (das ist denke ich so nicht rausbekommbar, es sei denn, die Hersteller geben darüber auskunft)
Ich weis aber, bessere Controller (inkl. Cache) lesen auf Verdacht schon immer die nächsten Sektoren auf der HDD mit ein und schieben diese in den Cache, was dem Problem extrem entgegen kommt. Denn so geschieht die nächste Abhandlung direkt im Cache des Controllers, was deutlich fixer von statten geht.

EDIT:
Moment die zweite, ich glaub was ich da grad geschrieben hab war auch bisschen Mist. Denn wenn man die Anzahl der HDDs weiter erhöht auf sechs zum Beispiel, geht es wieder nicht auf. Und das bei beiden nicht. Mit 64KB Stripesize wäre die Aufteilung dann bei 10/10/10/10/10/14... (Raid 5)
Irgendwie kann das nicht sein, oder?

Oder ist die Stripesize Einstellung auf dem Controller das, was die HDDs pro Stück drauf bringen? Ne, kann eigentlich auch nicht sein...
 
Zuletzt bearbeitet:
Im Prinzip solltest du doch recht haben. Ich kenns eigentlich auch nur so dass die Stripesize über alle HDDs rechne, und nicht nur die Nutzdaten betrachte.
Ich wollt underclocker nur nicht widersprechen ohne mich nochmal zu informieren :P

Deine Letzte Frage kann uns wohl nur direkt der Hersteller beantworten.

Was also den Test angeht: bitte mit 3 und 4 HDDs testen, wenn es die Zeit zulässt. Bin mal gespannt was dabei rauskommt

Edit:
fdsonne schrieb:
Der Schreibvorgang der Paritätsdaten dauert also in jedemfall minimal länger...
Zum Vergrößern anklicken....

Das nicht, nur weil der Block größer ist müssen da auch nicht mehr Daten rein. Allerdings verschiebt sich damit unser geliebtes Alignment komplett. Scheiss 4K Emulation
 
Zuletzt bearbeitet:
WEM fällt was auf? Zugegeben marginaler Unterschied, aber sichtbar.

Ich habe bewusst die letzten 3 Nummern der Serie drangelassen!

4f4erlfqv.jpg


Hier der unverkleinerte Link: http://www.abload.de/img/4f4erbel6.jpg

Sind heute gekommen, alle mit Garantie, gut kenne ich bei dem Händler auch nciht anders.

Übringens Jungs: D A N K E! Hätte mir ja auch mal einer sagen können, dass ich erst 4 mal die FW updaten sollte! Naja, mit mir kann man es ja machen.

So jetzt gehts an Raid5 konfigurieren und Background Init, heut Abend gibts dann die benches. Leise und saukühl sind die Dinger schon mal..
 
Kannst du erstmal mit einen RAID5 aus drei HDDs starten und anschließend nochmal mit einem RAID5 aus vier HDDs die gleichen Benchmarks durch laufen?
 
meine 4 HD204UI sind bis jetzt noch absichtlich OHNE Firmware Update! Werde ich aber auch noch machen.
 
Schau Dir mal die Gehäuse der 23 und 20 und der 36 und 33 an. Die Knubbel in dem silbernen Deckel sind einmal relativ deutlich, anderesmal wie niedergebügelt/ weich.

Ich würde ja nix sagen, mir fällt nur auf, dass es grad bei nem 10er Sprung von 20 auf 30 ist...

Ist sehr wahrscheinlich völlig unwichtig und stanztechnisch, ist mir eben nur aufgefallen weils grade so da lag.

45% Init...
 
Achso, joa...das ist dann aber nur ein äußerliches Merkmal. Vielleicht war da die Tiefziehpresse anders eingestellt oder es war einfach nur eine andere Presse. Aber scheint ja noch innerhalb der Toleranzen zu sein... ;)
 
Here we go:

Folgende Logik gilt für alle Bildreihen:

--> Alle am Areca 1261ML
--> 512MB Cache
--> jeweils 3 Läufe
--> ATTO, Diskmark 2.2 und Hd Tune Pro wurden getestet
--> beim write Test wurde mit leerem Raid5 Verbund gebencht


Links der "Controllbench" mit 8 x 1 TB WD im Raid 6
Mitte der Bench mit 4 x F3 Samsung HD203 2 TB Disks im Raid 5
Rechts der Bench mit den neuen 4 x F4 Samsung HD204 2TB Disks im Raid 5

atto8x1tbwdtfwy.jpg
atto4xf203uie5.jpg
atto4xf204jh6r.jpg


diskmark8x1tbwdhhch.jpg
diskmark4xf203hi6c.jpg
diskmark4xf204ni6m.jpg


hdtunepro8x1tbwdwcb5.jpg
hdtunepro4xf2030ifk.jpg
hdtunepro4xf204litk.jpg


Writebench

hdtunepro4xf204writecfhn.jpg


Hier noch ein Windows Copy Bench:

kopierenvon112gbeh52.jpg


Bisher soweit okay. Jetzt mach ich das Raid mal voll und zwar mit 3 Copy strömen.
 
Zuletzt bearbeitet:
Ich mach jetzt nochmal aktuelle mit CDM 3.01, keine Ahnugn warum ich noch den 2.2. hab
 
Na, das sieht doch sogar im Vergleich zu den F3 viel besser aus. Frage mich gerade, warum die F3 beim CDM im sequentiellen Bereich so schlecht abschneiden...

Tekkno_Frank: Wie lange hat das Initialisieren bei den F4 gedauert? Scheint ja recht schnell gegangen zu sein...
 
Weiß ich auch nicht. WErde das mal checken, das Raid5 aus den F3ern ist zu 85% voll.
Gott ich hab zu viel P0rn :lol::lol::lol::lol::lol::lol:

Spässle!

Ca. 2,5 Stunden, allerdings als Foreground nicht als Background Init! Wichtitsch!
 
Was hat das mit den 2199 MB im HDTune zu sagen? Ist dein Array nur so groß? Oder zeigt das Tool nicht mehr an?
 
Tool zeigt nicht mehr an, bencht aber alles

Ach ja, wen es interssiert.... Server
 
Zuletzt bearbeitet:
Komisch, also bei mir dauert das Initialisieren ziemlich lange, nach Rechnung ca. 2 1/2 Tage. Kann das am deaktivierten Festplattencache liegen? Hattest du den auch vor dem Initialisieren deaktiviert?
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh