[alfora]

Original geschrieben von günther
Es scheint mir deshalb, alsob das Win-Defragtool nicht so besonders sei.

Zunächst mal danke für die Blumen.

Das mit dem Defragmentierungsprogramm von Windows und "nicht so besonders" möchte ich aber nicht so stehenlassen. Das Programm tut ja das, was von ihm verlangt wird und macht das auch ganz gut. Die Programme der anderen Hersteller machen halt noch andere Dinge aber so richtig merkbar sind die Unterschiede im Normalbetrieb nicht.

In vielen Fällen hat es z.B. keinen Sinn, alle Dateien zu defragmentieren. Ob eine 50 MB-Videodatei in einem, zwei, oder fünf Fragmenten auf der Platte liegt ist z.B. vollkommen egal.

Traurig finde ich es eher, dass auch NTFS diese dumme Eigenschaft hat, Dateien fast automatisch zu fragmentieren. Da sind andere Dateisysteme um Klassen besser. Jetzt hat Microsoft noch dazu die Entwicklung an WinFS eingestellt, das heißt, das wird auch noch in den nächsten Jahren so bleiben und ein regelmäßiger Defragmentierungsdurchlauf bleibt unter Windows niemandem erspart.

@Thomas: Lies Dir nochmal genau durch, was ich bei diesem Punkt geschrieben habe. Die Texturen der Megaszenerie werden ja NIE verändert. Sie liegen einfach auf der Platte und werden vom FS9 irgendwann gelesen.

Meines Wissens sollte es demnach reichen, das Verzeichnis der Megaszenerie komprimieren zu lassen und danach eine Defragmentierung durchzuführen. Dadurch werden die kleinen Löcher aufgefüllt und die Dateien zusammengerückt.

Laut den Microsoft-Knowledge Base-Artikeln 307987 und 251186 werden die Dateien automatisch dekomprimiert und nach dem Schließen wieder komprimiert. Ich glaube, das gilt aber nur, wenn man die Datei auch bearbeitet hat (typisches Word-Dokument oder so) aber nicht, wenn sie nur gelesen wurde.

Wenn nur gelesen wird aber nicht geändert und wieder abgespeichert, dann wird auch nichts neu komprimiert.

Siehe 251186

Da die NTFS-Komprimierung sehr prozessorintensiv ist, sind die Performancekosten deutlicher auf Servern spürbar, die oftmals prozessorgebunden sind. Server mit hoher Last und erheblichem Volumen an Schreibzugriffen sind schlechte Kandidaten für die Dateikomprimierung, während die Verschlechterung der Performance bei schreibgeschützten Servern, Servern, auf denen vorwiegend Lesezugriffe stattfinden, oder Servern mit geringer Last möglicherweise unerheblich ist.

Der c't-Test war übrigens in Heft 21/05. Dort ist das genauer beschrieben.

Alles klar?