Clustergrößen bei Festplatten und was ist der Vorteil davon?
Was hat es für Auswirkung wenn ich eine Festplatte mit 16/32/64/128/256/512kb /4096kb/8192kb Formatiere ? Seit Win2000 sind die Clustergrößen immer hör gegangen. Win10 verwendet Standard 8192kb pro Cluster. Ich habe gemerkt als eine Multiboot PC einrichten wollte aus XP, Win7 und Win8.1 das Win 8.1 ständig die Clustergrößen umschrieb und mir dadurch diverse Daten geplättet hat. Hat man dann XP gestartet hat XP dann wieder die Clustergrößen zurück geändert. Daher weiß ich das ein Mulitbootsystem nur bis Win7 möglich.
Was ist der große Unterschied zwischen den Clustergrößen, speichert man schneller die Daten ? Oder lässt sich eine Datei in großen Clustergrößen schneller Finden?
2 Antworten
Vorbetrachtung
Die Clustersize oder Blocksize gibt an in welchen "Stuecken" Daten ins Dateisystem geschrieben werden.
D.h.: Bei einer Blocksize von 4K werden immer 4K grosse Bloecke geschrieben. Wenn eine Datei nur 2K gross ist, bleiben entsprechend 2K "leer"; wenn eine 8K Datei gross ist, werden also 2 Bloecke verbraucht.
Normalerweise bzw. bei den meisten IO Pattern kann man die Blocksize beim default des Filesystems belassen; das sind in der Regel 4K.
Nun aber zu den Fragen:
Was ist der große Unterschied zwischen den Clustergrößen, speichert man schneller die Daten ? Oder lässt sich eine Datei in großen Clustergrößen schneller Finden?
Wie so oft: Kommt immer drauf an (:
Theorie
Ganz generell gilt erst einmal: Je kleiner die Bloecke, desto mehr Zugriffe braucht man um Daten zu lesen oder schreiben. Je groesser die Bloecke desto weniger.
Daraus laesst sich ableiten, dass das lesen/schreiben in kleine Bloecke mehr "kostet", in dem Fall Performance, sprich: es ist langsamer.
Im Umkehrschluss ist das lesen/schreiben in grosse Bloecke schneller.
Anders ausgedrueckt: der Datendurchsatz - gemessen z.B. in MB/s - wird mehr, je weniger Zugriffe man hat. Darum wird ein Benchmark auf eine HDD oder SSD auch bei groesseren Blocksizes ein besseres Ergebnis liefern als bei niedrigen.
Neben dem Durchsatz gibt es noch eine zweite relevante Groesse, die IOPS (IO Operationen pro Sekunde). Ggf. fuehrt das hier aber zu weit, dazu kann ich bei Bedarf noch was hier drunter schreiben :)
Praxis
Soweit erstmal zur Theorie, in der Praxis gibts dann aber auch Daten die in das Dateisystem geschrieben werden wollen und da faengts an kompliziert zu werden.
Wenn auf meinem Computer eine Applikation laeuft, die als IO Pattern immer nur 2-4K grosse Dateien liest/schreibt wird meine Gesamtperformance bei einer Blocksize von z.B. 32K dennoch langsamer, weil fuer jede 2-4K immer 32K eingelesen oder geschrieben werden muessen. Bei ein paar Lese-/Schreib-Operationen faellt das wenig ins Gewicht, bei ein paar Tausend dann aber schon.
Andersrum gilt dasselbe: Wenn eine Applikation benutzt wird, die immer Files von 16K Groesse anlegt, wird es eine merkliche Performance Steigerung bringen, wenn man die Blocksize von 4K auf 16K hochsetzt. Somit muessen nicht fuer jede Datei 4 Bloecke geschrieben werden, sondern eben nur einer (was dann wieder schneller ist).
Wenn man also das IO Pattern seiner Applikationen kennt und dieses eher homogen ist, kann es sehr viel bringen sich mit der Blocksize / Clustersize des Dateisystems auseinanderzusetzen und diese zu tunen.
Bonusmaterial
Das obige bezieht sich auf eine "Dimension" die betrachtet wird, naemlich einen Computer mit einer Festplatte (egal ob HDD oder SSD).
Man hat in der Praxis aber auch gerne ein paar Dimensionen mehr ;)
Beispiel 1:
Das Dateisystem liegt auf einem RAID Array. Ein RAID Array hat eine konfigurierbare Chunk Size. Diese gibt genau wie die Blocksize/Clustersize an in welchen "Stuecken" Daten in das Array geschrieben werden.
Im allerbesten Fall passt die Blocksize vom Dateisystem zur Chunk Size vom RAID Array oder ist zumindest ein Vielfaches oder Teiler davon.
Wenn beide Groessen stark unterschiedlich sind, z.B. 16K Chunk Size und 10K Blocksize wuerde das folgendes bedeuten:
Der erste 10K Block passt in einen 16K Chunk rein. Das ist gut. Im Chunk sind noch 6K Platz.
Vom zweiten 10K Block passen ja nur noch 6K in den Chunk, die verbleibenden 4K Block muessen in den naechsten Chunk, also auf die naechste Festplatte. D.h. um den zweiten Block zu lesen, muss man von zwei Festplatten lesen anstatt von einer.
Das ginge dann immer so weiter. Man spricht bei sowas von einem Misalignment
Auch hier wirds in Summe sehr stark messbar und spuerbar fuer die Performance.
Beispiel 2:
Das Dateisystem liegt auf einem virtuellen Volume (weil der Computer eine VM ist) und dieses wiederrum liegt auf einem RAID Array.
Dann muessen also die Blocksize in der VM zur Blocksize des virtuellen Volumes passen und das wiederrum zur Chunk Size vom RAID Array.
Im duemmsten Fall passen dann die Dateisystem Bloecke nicht sauber in die Volume Bloecke und die Volume Bloecke gehen ueber die Chunk Grenzen hinaus.
Beispiel 3 erspare ich dir mal, aber es gibt noch mannigfaltige weiter Dimensionen, z.B. Pages von Storage Engines bei Datenbank Systemen usw. usw.
Der einzige wirkliche Vorteil bei großen Clustern ist, dass man damit größere Platten formatieren kann - die maximale Anzahl von Clustern ist begrenzt, und für ältere Dateisysteme ist diese Anzahl auf sehr viel kleinere Platten ausgelegt als man heute bekommt.
Bei aktuellen Dateisystemen sollte man mit Clustergrößen keine Probleme haben.