@Krautmaster
das was du beschreibst mit der Aufteilung ist zwar grundsätzlich erstmal richtig, aber es ist sogut wie zu vernachlässigen, vor allem, wenn man mit Dateien hantiert, welche mehrere MB groß sind...
Bei 16KB Stripe und 32KB Clustergröße und 4 Platten sieht es folgendermaßen aus:
Ein Sektor ist wohl idR 512Byte groß, 16KB bedeuten also 32 aufeinander folgende Sektoren.
Schreibt/ließt man eine 32KB Datei, wird von Platte 1 ein 16KB Block und von Platte 2 ebenso ein 16KB Block geschrieben/gelesen. Es arbeiten also beim lesen 2 und beim schreiben 3 Platten. Platte 3 macht nix, weil eben die Daten auf Platte 3 nicht mehr zu der Datei gehören.
Schreibt/ließt man beispielsweise eine 64KB Datei, wird von Platte 1 ein 16KB Block, dann von Platte 2 ein 16KB Block, dann von Platte 3 ein 16KB Block und wieder von Platte 1 ein 16KB Block gelesen/geschrieben.
Warum nicht von Platte 4? Weil auf Platte 4 die Paritätsdaten für einen 16KB Block der Platten 1-3 liegen.
Es arbeiten also beim lesen 3 und beim schreiben alle 4 Platten. Nur das beim lesen eine Platte (in dem Fall die erste) zwei 16KB Blöcke lesen muss, die Zeit verdoppelt sich also.
Treibt man das ganze jetzt weiter fort. Bei beispielsweise 1MB = 1024KB = 64 Blöcke a 16KB, müssen Platte 2 und 3 jeweils 21 Blöcke und Platte 1 dann 22 Blöcke lesen.
Die Zeit steigt um 1/22. Der Nachteil wird also um so kleiner, je größer die Datei wird...
Da wohl keiner bei diesen Einstellungen ausschließlich mit kleinen Dateien im unteren KB Bereich rumhantieren wird, relativiert sich das Problem von selbst.
Aber da fällt mir grad noch was anderes ein, viel wichtiger ist die Erstellung der Partitionen, bzw. wo diese auf dem Datenträger anfängt.
Linux und Windows ab Vista/2008 Server haben da keine Probleme, bei 2003 Server und älter kommt hinzu, das eine MBR genau 63 Sektoren breit ist, und Windows in dem Fall bei Sektor 64 die Partition anfängt.
Da die Sektoren sich bei Festplatten auf Spuren/Tracks befinden findet bei dieser "krummen" Einstellung recht häufig ein Spurwechsel statt, der eine Kopfbewegung zur Folge hat, was Verzögerung (je nach Plattengeschwindigkeit) mitsich bringt.
Nehmen wir an, eine Platte hat 64 Sektoren pro Track, sprich 32KB pro Spur, so müssten bei jedem zweiten 16KB Block, der gelesen/geschrieben wird auf ein und der selben Platte ein zusätzlicher Spurwechsel durchgeführt werden.
Würde man in dem Fall die Stripesetgröße auf 32KB hochdrehen, wäre es sogar bei jedem Zugriff (obwohl gar keiner gemacht werden müsste) und bei 64KB sogar zwei mal pro Zugriff. (obwohl nur einer nötig wäre, weil zwei Spuren genau 64KB Daten fassen)
Aber genaug von dem kleinen HDD Exkurs meinerseits
@DaReal
ich würde sagen, wähle die Stripsetgröße anhand deiner Daten, um so größer die Daten sind, desto mehr machen große Stripes Sinn. Weil einfach mehr zusammenhängende Blöcke gelesen werden.
Der Umstand von Krautmaster relativiert sich wie grad beschrieben bei großen Files sowieso... Viel verkehrt machen kann man da nicht unbedingt...
Man sollte nur beachten, bei einer zu große Clustergröße und zu kleinen Files verschänkt man unnötig Speicherplatz auf der HDD/dem Array.
.
