“There is no Spoon” – Neo, The Matrix
Die eigentliche Idee hinter der Defragmentierung von Dateisystemen ist, die Daten in sequenzieller Reihenfolge auf der Festplatte zu speichern, um beim Suchen in den Dateien Zeit zu sparen. Das klappt ganz gut mit einem Stück “Spinning Rust” (HDD) für sich alleine, weil die Daten letztendlich auf Sektoren abgelegt werden und jeder dieser Sektoren eine „Heimatadresse“ auf dem Laufwerk hat. Diese Adressen sind statisch und lokalisieren die Daten in drei Dimensionen (Cylinder, Head, Sector). Eine Latenz beim Datenzugriff entsteht durch Justage des Schreib-/Lesekopfes an die korrekte Position, um auf den jeweiligen Sektor zuzugreifen, wenn er unter dem Kopf vorbei flitzt.
RAID-Level-Virtualisierung übersetzt diese Adressen bereits in ein virtuelles Adress-Schema, das nichts mehr mit dem physikalischen Aufbau der Disk zu tun hat. Somit ist Defragmentierung hier schon nahezu wirkungslos. Sie kann allerdings noch leichte Vorteile bei großen Schreibvorgängen bringen, da sich die Wahrscheinlichkeit von sogenannten “Full Strokes” erhöht und damit weniger der aufwändigen Read-Modify-Write-Operationen stattfinden, die zu erheblichen Leistungseinbußen beim Schreiben führen können.
SDS-Abstraktion, wie sie mit SANsymphony-Pools stattfindet, legt eine weitere Verschleierungsschicht auf das Adress-Schema und erzeugt eine weitere, optimierte Beziehung der logischen Adresse zur physikalischen „Heimatadresse“, während das Dateisystem von dem ganzen Zauber keine Ahnung hat. Um die Matrix nochmal zu zitieren: “You think that’s air you’re breathing” – Morpheus; sollten Applikationen in SDS-Umgebungen Latenzprobleme zeigen, wird Defragmentierung höchstwahrscheinlich keine Abhilfe schaffen. Hier macht es mehr Sinn, die zugrunde liegende Hardware zu überprüfen.
Es brennt Licht, aber keiner ist Zuhause!
Wie oben beschrieben verschiebt die Defragmentierung Daten für schnelleren Zugriff. Um das besser zu verstehen nehmen wir ein Beispiel aus dem realen Leben. Ein Postbote wird die Briefe in seiner Tasche so anordnen, dass er diese nach Hausnummern sortiert vorfindet. Somit kann er eine Straße nach der Anderen ablaufen und im Vorbeigehen die Post einwerfen. Mit jeder anderen Sortierung würde er ständig zwischen den Häusern hin und her laufen, und jede Menge Zeit verschwenden anstatt Post zuzustellen.
Wenn wir jetzt Auto-Tiering in der SDS-Umgebung nutzen, werden die physikalischen Adressen der Daten ständig so angepasst, dass der optimale Zugriff gewährleistet ist, während sich die logische (virtuelle) „Heimatadresse“ im Dateisystem unverändert zeigt. Der direkte Effekt sind verbesserte Zugriffszeiten.
Ungeachtet der physischen Verschiebung durch das Auto-Tiering, verschiebt die Defragmentierung die Daten zusätzlich auf andere logische (virtuelle) Adressen und damit unter Umständen auf physikalische „Heimatadressen“ mit weniger optimalen, undefinierten Zugriffsbedingungen. Damit können aus schnellen Zugriffszeiten vor Defragmentierung überraschend langsame nach Defragmentierung werden.
Zurück vom Postboten. Der Postbote hat die sortierten Briefe in seiner Tasche und will die Straße ablaufen, die Bewohner haben sich einem „Wohnungstausch-Programm“ angeschlossen und Nachsende-Adressen auf den Briefkästen hinterlassen. Der arme Kerl muss sich jetzt mit der Situation herumschlagen und die neuen Adressen mit der Sortierung überein bekommen, oder kurzfristig, mit viel Rennerei die Post verspätet zustellen.
Erfahren Sie mehr darüber, wie Datenspeicherlösungen Ihre IT-Servicebereitstellung und -leistung entscheidend verändern. Klicken Sie hier, um heute eine voll funktionsfähige Testversion zu erhalten.
