von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Das 1x1 der Festplatten-Defragmentierung (1)
Beispiel einer Fragmentierung
Wir nehmen zur Verdeutlichung des Gesagten eine Beispieldatei von 128 KByte Größe: Üblicherweise werden die Daten bei NTFS keineswegs direkt in – von der Position und vom LCN her – aufeinanderfolgende Cluster geschrieben, sondern das System lässt die Daten dort fallen, wo gerade freie (beschreibbare) Cluster in der Nähe des Plattenkopfes zu finden sind. Der Versuch, möglichst große, zusammenhängende Blöcke (Extents genannt) zu bilden, scheitert leider mit zunehmender Datendichte eines Laufwerks. Bei einer weitestgehend leeren Platte ist dieses Verfahren sinnvoll und noch performant, auf einer Partition jedoch, wo sich der Dateninhalt sowie die Dateigrößen ständig ändern (bei Fileservern zum Beispiel), kommt es zu einer unnötigen Verzögerung.
Unsere Beispieldatei von 128 KByte Größe würde also bei der Standardeinstellung des Betriebssystems (4 KByte/Cluster) in genau 32 Cluster hineinpassen (128 KByte/4 KByte). Diese 32 Cluster können im Idealfall aufeinanderfolgend sein, die Praxis sieht jedoch leider anders aus. Je mehr Cluster eine Datei belegt, desto größer ist die Wahrscheinlichkeit, dass der Plattenkopf mehrere Bereiche der Festplatte ansteuern muss, um die Datei abzulegen. Eine Datei, die keine aufeinanderfolgenden Cluster (vom LCN her) belegt, gilt als fragmentiert.
Gleiches gilt entsprechend auch für das Lesen der Datei. Somit sind die von Benchmark-Applikationen ermittelten Datendurchsatz-Werte für eine Festplatte in der Praxis nicht oder in nur sehr seltenen Fällen zu erzielen. Daher lassen sich auch zwei Werte des Datendurchsatzes unterscheiden: das sequenzielle Lesen (aufeinanderfolgende Cluster) und das zufällige Lesen (Random Read).
In der Praxis können beide Werte je nach Plattenart und Modell um bis zu 800 Prozent auseinanderliegen. Gleiches gilt für Schreibvorgänge, wobei beim Schreiben eine höhere Genauigkeit erforderlich ist und daher die Schreibwerte (sequenziell wie auch zufällig) in der Regel immer unter den reinen Lesewerten liegen.
Was wir also mit dem Ändern/Erhöhen der Clustergröße vorhaben, ist zweierlei: Zum einen erzielen wir eine bessere Schreib- und Leseeffizienz dadurch, dass der Plattenkopf nicht zu oft neu positioniert werden muss. Zum anderen senken wir die Fragmentierungsrate der Datei, indem wir die Clustergröße im Idealfall der Dateigröße gleichsetzen. Theoretisch (vergleiche jedoch Bild 4) ist die maximale Anzahl von Datenfragmenten einer Datei mittels der Formel
Dateigröße / Clustergröße = X
zu ermitteln, wobei X immer eine ganze Zahl ist. Errechnet sich so ein Wert von beispielsweise 7,2 Clustern, so belegt die Datei effektiv 8 Cluster. Pro Cluster kann der Inhalt nur einer Datei geschrieben werden, ein eventuell freibleibender Platz kann und wird nicht mit Daten einer anderen Datei belegt. Gerade diese Eigenheit der Cluster sollten wir bedenken, wenn es darum geht, die Clustergröße vernünftig anzupassen, damit der "Verschnitt" (verschwendeter und nicht belegbarer Plattenplatz) möglichst gering bleibt.
Auswirkungen der Fragmentierung
Wir sehen anhand der Bilder 1 und 4, dass Dateien fragmentieren. Dieser Zustand tritt bereits direkt nach der frischen Installation eines Windows XP- oder Server-Systems auf. Die Anzahl der Fragmente muss jedoch in keinem Zusammenhang zur Dateigröße stehen. Sehen Sie sich dazu bitte die letzten zwei Zeilen in Bild 4 an: zwei Dateien, eine mit 9 MByte und eine mit 377 KByte, haben eine fast gleiche Anzahl von Fragmenten.
Zudem ist die zuvor genannte theoretische Ermittlung für die maximale Anzahl der Dateifragmente mittels der Datei- und Clustergröße nicht immer korrekt – werfen Sie dazu bitte einen Blick auf den hervorgehobenen Bereich in Bild 4: Die markierte Datei von 24 KByte Größe dürfte rein rechnerisch maximal sechs Fragmente aufweisen, in der Praxis werden vom System 306 Fragmente angezeigt. Bei einer Clustergröße von 4 KByte belegt somit diese Datei 306 mal 4 = 1.224 KByte an Platz auf der Festplatte – 1.200 KByte mehr als erforderlich und verbunden mit unnötig vielen zusätzlichen (genau 300 an der Zahl) und zeitraubenden Plattenkopfpositionierungen beim Lesen der Dateiinhalte.
Gerade Log-Dateien des Systems weisen diese Eigenschaft bevorzugt auf, ebenso wie Profildateien der User (insbesondere die ntuser.dat, die bei einer Größe von zirka 1,5 MByte oft über 6.000 Fragmente aufweist). Damit haben wir auch eine – wenn auch nicht die einzige – Ursache für die häufig vorkommenden Probleme mit Benutzerprofilen, die oft nur durch das Löschen eines Profils zuverlässig zu beheben sind.
Im zweiten Teil unseres Online-Workshops "Das 1x1 der Festplatten-Defragmentierung" geben wir praktische Empfehlungen, wie Sie die Clustergröße je nach Systemnutzung individuell festsetzen und was bei einer wirkungsvollen Defragmentierung zu beachten ist.
ln/dr/Nikolay Taschkow
Wir nehmen zur Verdeutlichung des Gesagten eine Beispieldatei von 128 KByte Größe: Üblicherweise werden die Daten bei NTFS keineswegs direkt in – von der Position und vom LCN her – aufeinanderfolgende Cluster geschrieben, sondern das System lässt die Daten dort fallen, wo gerade freie (beschreibbare) Cluster in der Nähe des Plattenkopfes zu finden sind. Der Versuch, möglichst große, zusammenhängende Blöcke (Extents genannt) zu bilden, scheitert leider mit zunehmender Datendichte eines Laufwerks. Bei einer weitestgehend leeren Platte ist dieses Verfahren sinnvoll und noch performant, auf einer Partition jedoch, wo sich der Dateninhalt sowie die Dateigrößen ständig ändern (bei Fileservern zum Beispiel), kommt es zu einer unnötigen Verzögerung.
Unsere Beispieldatei von 128 KByte Größe würde also bei der Standardeinstellung des Betriebssystems (4 KByte/Cluster) in genau 32 Cluster hineinpassen (128 KByte/4 KByte). Diese 32 Cluster können im Idealfall aufeinanderfolgend sein, die Praxis sieht jedoch leider anders aus. Je mehr Cluster eine Datei belegt, desto größer ist die Wahrscheinlichkeit, dass der Plattenkopf mehrere Bereiche der Festplatte ansteuern muss, um die Datei abzulegen. Eine Datei, die keine aufeinanderfolgenden Cluster (vom LCN her) belegt, gilt als fragmentiert.
Gleiches gilt entsprechend auch für das Lesen der Datei. Somit sind die von Benchmark-Applikationen ermittelten Datendurchsatz-Werte für eine Festplatte in der Praxis nicht oder in nur sehr seltenen Fällen zu erzielen. Daher lassen sich auch zwei Werte des Datendurchsatzes unterscheiden: das sequenzielle Lesen (aufeinanderfolgende Cluster) und das zufällige Lesen (Random Read).
In der Praxis können beide Werte je nach Plattenart und Modell um bis zu 800 Prozent auseinanderliegen. Gleiches gilt für Schreibvorgänge, wobei beim Schreiben eine höhere Genauigkeit erforderlich ist und daher die Schreibwerte (sequenziell wie auch zufällig) in der Regel immer unter den reinen Lesewerten liegen.
Dateigröße / Clustergröße = X
zu ermitteln, wobei X immer eine ganze Zahl ist. Errechnet sich so ein Wert von beispielsweise 7,2 Clustern, so belegt die Datei effektiv 8 Cluster. Pro Cluster kann der Inhalt nur einer Datei geschrieben werden, ein eventuell freibleibender Platz kann und wird nicht mit Daten einer anderen Datei belegt. Gerade diese Eigenheit der Cluster sollten wir bedenken, wenn es darum geht, die Clustergröße vernünftig anzupassen, damit der "Verschnitt" (verschwendeter und nicht belegbarer Plattenplatz) möglichst gering bleibt.
Auswirkungen der Fragmentierung
Wir sehen anhand der Bilder 1 und 4, dass Dateien fragmentieren. Dieser Zustand tritt bereits direkt nach der frischen Installation eines Windows XP- oder Server-Systems auf. Die Anzahl der Fragmente muss jedoch in keinem Zusammenhang zur Dateigröße stehen. Sehen Sie sich dazu bitte die letzten zwei Zeilen in Bild 4 an: zwei Dateien, eine mit 9 MByte und eine mit 377 KByte, haben eine fast gleiche Anzahl von Fragmenten.
Zudem ist die zuvor genannte theoretische Ermittlung für die maximale Anzahl der Dateifragmente mittels der Datei- und Clustergröße nicht immer korrekt – werfen Sie dazu bitte einen Blick auf den hervorgehobenen Bereich in Bild 4: Die markierte Datei von 24 KByte Größe dürfte rein rechnerisch maximal sechs Fragmente aufweisen, in der Praxis werden vom System 306 Fragmente angezeigt. Bei einer Clustergröße von 4 KByte belegt somit diese Datei 306 mal 4 = 1.224 KByte an Platz auf der Festplatte – 1.200 KByte mehr als erforderlich und verbunden mit unnötig vielen zusätzlichen (genau 300 an der Zahl) und zeitraubenden Plattenkopfpositionierungen beim Lesen der Dateiinhalte.
Gerade Log-Dateien des Systems weisen diese Eigenschaft bevorzugt auf, ebenso wie Profildateien der User (insbesondere die ntuser.dat, die bei einer Größe von zirka 1,5 MByte oft über 6.000 Fragmente aufweist). Damit haben wir auch eine – wenn auch nicht die einzige – Ursache für die häufig vorkommenden Probleme mit Benutzerprofilen, die oft nur durch das Löschen eines Profils zuverlässig zu beheben sind.
Im zweiten Teil unseres Online-Workshops "Das 1x1 der Festplatten-Defragmentierung" geben wir praktische Empfehlungen, wie Sie die Clustergröße je nach Systemnutzung individuell festsetzen und was bei einer wirkungsvollen Defragmentierung zu beachten ist.
<<Vorherige Seite Seite 2 von 2
ln/dr/Nikolay Taschkow
