5 Aug
2003
5 Aug
'03
09:55
On Tue, Aug 05, 2003 at 11:22:04AM +0200, Matthias Wieser wrote: > Immer dann, wenn einen die verhältnismäßig geringe > Geschwindigkeit von Festplatten stört, nämlich beim > erstmaligen Lesen, ändert ein großer Cache kaum etwas. Solange die Frags groß genug sind (größer als der Read-Ahead des Kernels, besser so groß wie eine Spur, noch besser größer als der Cache der Platte), interessiert es nicht, ob eine Datei fragmentiert ist. BSD FFS fragmentiert Dateien zum Beispiel absichtlich ("long seek") in Stücke von etwa 1/8 der Größe einer CG: Wenn ein Dateifragment mehr als 1/8 der CG auffüllt, wechselt FFS zu einer anderen CG und schreibt die weiteren Sektoren dort hin. Dadurch werden alle CGs gleichmäßig aufgefüllt und FFS hat eine Chance, Dateianfangsblöcke in der Nähe der jeweiligen Inodes zu positionieren. Das ist wichtiger als die ganze Datei am Stück zu schreiben und eine große Datei ist in FFS IMMER fragmentiert. In ext2 ist es ganz ähnlich: Zwar kennt ext2 keine long seeks, aber durch die Struktur von ext2 in Blockgruppen ist jede Datei, die länger ist als eine Blockgruppe zwangsläufig fragmentiert. >> [ Meine Desktop-Kiste mit 1 GB RAM, davon 720 MB Cache ] > Da mag bei Dir so sein, bei vielen anderen (den meisten?!) > läuft (gerade bei den derzeitigen Temperaturen) ihr PC maximal > ein paar Stunden am Stück. Das reicht aus, um den Cache aufzuheizen. Diese Personen verwenden in der Regel auch weniger viele unterschiedliche Programme als ich das im Laufe einer Laufzeit meines Rechners mache. So ergibt sich ein ähnliches Bild, oft schon nach 15 Minuten, jedoch auf einem entsprechend niedrigeren Niveau. > > Das ist eine von drei bekannten Möglichkeiten, die Daten auf > > einer Platte anzuordnen. In > > Das ist die mit Abstand verbreitetste. Nichtsdestotrotz ist eine unbedingte lineare Anordnung bei Platten, die nicht diese Geshcwindigkeitsverteilung haben nicht förderlich, sondern sogar kontraproduktiv (jedoch nicht kontraproduktiver als gar nicht zu defragmentieren, denn auch diese Anordnung geht in den Caches und Betriebssystemstrategien vollkommen unter). > > - keinen Buffer Cache hat. > - oder wenn die Partition recht voll ist Besser: Größere Platte kaufen. Die hat dann auch ein neueres Interface, einen größeren Cache und ist generel schneller. Dieser Effekt ist weit stärker als jeder Gewinn, den Defragmentierung selbst im theoretischen Optimalfall haben kann. > - wenn es einem beim Lesen von z.B. CD Images auf maximalen Durchsatz > ankommt Ähem, 50x Speed = 7.500 KB/sec. Zum Vergleich: kris:~ # hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 4.24 seconds = 15.09 MB/sec kris:~ # hdparm -I /dev/hda| head -10 /dev/hda: ATA device, with non-removable media Model Number: HITACHI_DK23CA-20 Serial Number: 11MVXL Firmware Revision: 00H1A0G1 Standards: Used: ATA/ATAPI-5 T13 1321D revision 3 Supported: 5 4 3 2 & some of 6 Das ist eine Notebook-Platte in einem Inspiron 8100. valiant:~ # hdparm -t /dev/hdd /dev/hdd: Timing buffered disk reads: 64 MB in 1.41 seconds = 45.39 MB/sec valiant:~ # hdparm -I /dev/hdd | head -10 /dev/hdd: ATA device, with non-removable media Model Number: WDC WD800JB-00CRA1 Serial Number: WD-WMA8E2420882 Firmware Revision: 17.07W17 Standards: Supported: 5 4 3 2 Likely used: 6 Ich denke, das kann man entspannt sehen. Kristian