In diesem Thread:
http://www.nickles.de/static_cache/538591364.html
wurde das Problem der Defragmentierung angesprochen.
Und ich stellte fest - es gibt da Unklarheiten.
So defragmentiere ich regelmäßig und empfehle das auch - *Synthetic_codes* hingegen behauptet, es wäre überflüssig.
Einen Performance- Gewinn, wie so oft behauptet wird, habe ich tatsächlich noch nicht feststellen können.
Aber dafür andere nützliche Effekte. Die ich mal als reine Erfahrungswerte - ohne theoretische Begründung - nennen will:
- Ich habe zum Beispiel schon einigemale die Daten von Dateipartitionen wieder hergestellt, in die ein Image -im unbegründeten Vertrauen auf die Richtigkeit der Laufwerksanzeigen von Acronis- wieder hergestellt wurde.
(Acronis TrueImage zeigt nicht die gleichen Laufwerksbuchstaben an, wie sie unter XP dastehen)
Wurde diese Datenpartition zuvor defragmentiert, dann wurden Filme, mpeg usw auch in einem Stück gerettet - bei nicht defragmentierten Partitionen wurden diese Filme zwar auch restlos wieder hergestellt - aber in unverwendbaren Einzelteilen.
Das betrifft auch rar, iso und andere größere zusammenhängende Dateien.
- In nicht wenigen Fällen konnten Dateisystemfehler mit einer einfachen (space) Defragmentierung per O&O Defrag korrigiert werden.
Sehr viel nachhaltiger, als mit der Reparaturfunktion (Laufwerk > Eigenschaften > Extras > Jetzt prüfen > beide Häkchen rein) möglich war.
Und das betraf ausschließlich Dateisysteme, die nie defragmentiert wurden.
Das sind für mich die beiden Hauptgründe. Aber auch die Ausnutzung des Speicherplatzes sollte bedacht werden:
- Ich habe hier einmal etwas genau definiertes herausgepickt und dokumentiert.
Mittels des Cluster- Inspektors habe ich 2 nebeneinander liegende Blöcke aufgerufen.
Vor der Defragmentierung:
http://www.juekirs.de/Foren/nickles/def1.jpg
und unmittelbar daneben:
http://www.juekirs.de/Foren/nickles/def2.jpg
Nach der Defragmentierung:
http://www.juekirs.de/Foren/nickles/def3.jpg
http://www.juekirs.de/Foren/nickles/def4.jpg
Der leere Raum wurde aufgefüllt - keine Leerstellen mehr.
Hier mal eine Darstellung der Blöcke, wie sie O&O Defrag anbietet:
http://www.juekirs.de/Foren/nickles/def5.jpg
Schwarz - Logfile
Gelb - für MFT reserviert
Grün - in Benutzung befindliche MFT
Braun - pagefile.
Diese Dateien werden nicht berührt, nicht defragmentiert.
(Die in Benutzung befindlichen MFT auch als "fragmentiert" definiert, aber in Ruhe gelassen)
Blau - Dateien
Bei dieser Betrachtung lasse ich kleinkarierte (in meinen Augen, ja?) Betrachtungen über HDD- Lebensdauer mal außer Acht.
Es sollte mal wirklich nur um die Nützlichkeit oder Unsinnigkeit der Defragmentierung von NTFS- Systemen gehen, ok?
Ich würde mich über lehrreiche Kommentare zu diesem "Problem" sehr freuen.
Jürgen
Datenträger - Festplatten, SSDs, Speichersticks und -Karten, CD/ 19.540 Themen, 109.440 Beiträge
Bei dieser Betrachtung lasse ich kleinkarierte (in meinen Augen, ja?) Betrachtungen über HDD- Lebensdauer mal außer Acht.
Gerade das ist aber ein aufkommender Fakt. Auf dauer werden SSDs die herkömmlichen Platten die mit GiantMagnetoResistive Recording arbeiten ablösen. damit hast du dann eine SSD, deren Lebenszyklen mit jeder defragmentierung kürzer werden. Um den Effekt zu verdeutlichen habe ich unter Debian Lenny eine Virtuelle maschine mit vmware erstellt und deren Disk-Image auf eine debugfs-Partition gelegt. Debugfs bietet die möglichkeit eines inkrementellen logs, was wiederum bedeutet, dass man veränderungen am Dateisystem, zugriffe auf die einzelnen sektoren etc mitloggen und auswerten kann. Dann habe ich in der VM Xp-SP2 auf eine NTFS-Partition mit 5 GB installiert. Schlussendlich habe ich mit einem kleinen bash-script 500 Dateien variabler grösse aus /dev/urandom geholt, diese in die vm kopiert. dann davon die hälfte gelöscht, und weitere 250 aus urandom geleierte files reingeschoben. man könnte meinen dass das für eine anständige fragmentierung reicht oder?
Daraufhin habe ich smartdefrag laufen lassen. Das tool benötigte für die 5GB ca 20 minuten. das debugfs Log wies daraufhin eine durchschnittliche Schreibzugriffszahl je sektor von 17 aus. was bedeutet dass einmal defragmentieren auf einer SSD 17 Schreibzyklen verbrauchen würde, was bei derzeit afaik 5Millionen garantierten Schreibzyklen je Sektor8Ich glaube es sind 5kk, bin mir aber nicht sicher wie weit die technik atm ist) pro defragmentierungsvorgang 0,0000034% der lebensdauer verkürzt werden. Gerade im Privaten umfeld habe ich es an einigen PCs gesehen, dass hier gerne mal der Defragmentierer in den Task-Manager gehauen wird und dann täglich läuft. Klingt jetzt nach kinkerlitzchen, aber im jahr macht das konkret 0,1241% der SSD aus. Da ich an meinem Notebook eine CF-Karte über PCMCIA als Festplatte für das system betreibe, welche ein WearLevelingLog anlegt, kann ich weiter gehen, und konkrete daten für den normalverbrauch einer SSD angeben. Bei meiner CF sind dies im Mittel je Sektor 270.000 Schreibzugriffe.
Daraus ergibt sich bei einer MTBF von 5kk eine Lebensdauer der SSD um 18 Jahre mit defragmentieren,
eine Lebensdauer von 19Jahren ohne Defragmentieren.
Die meisten werden jetzt sagen WTF, das eine Jahr, allerdings sind hier ja nur mittelwerte angegeben, und durch das eingebaute Wear-Leveling von SSDs verkürzt sich die Zeit bis zum ersten ausfall mitunter bis auf ein Jahr, allein durch defragmentieren
Gerade das ist aber ein aufkommender Fakt. Auf dauer werden SSDs die herkömmlichen Platten die mit GiantMagnetoResistive Recording arbeiten ablösen. damit hast du dann eine SSD, deren Lebenszyklen mit jeder defragmentierung kürzer werden. Um den Effekt zu verdeutlichen habe ich unter Debian Lenny eine Virtuelle maschine mit vmware erstellt und deren Disk-Image auf eine debugfs-Partition gelegt. Debugfs bietet die möglichkeit eines inkrementellen logs, was wiederum bedeutet, dass man veränderungen am Dateisystem, zugriffe auf die einzelnen sektoren etc mitloggen und auswerten kann. Dann habe ich in der VM Xp-SP2 auf eine NTFS-Partition mit 5 GB installiert. Schlussendlich habe ich mit einem kleinen bash-script 500 Dateien variabler grösse aus /dev/urandom geholt, diese in die vm kopiert. dann davon die hälfte gelöscht, und weitere 250 aus urandom geleierte files reingeschoben. man könnte meinen dass das für eine anständige fragmentierung reicht oder?
Daraufhin habe ich smartdefrag laufen lassen. Das tool benötigte für die 5GB ca 20 minuten. das debugfs Log wies daraufhin eine durchschnittliche Schreibzugriffszahl je sektor von 17 aus. was bedeutet dass einmal defragmentieren auf einer SSD 17 Schreibzyklen verbrauchen würde, was bei derzeit afaik 5Millionen garantierten Schreibzyklen je Sektor8Ich glaube es sind 5kk, bin mir aber nicht sicher wie weit die technik atm ist) pro defragmentierungsvorgang 0,0000034% der lebensdauer verkürzt werden. Gerade im Privaten umfeld habe ich es an einigen PCs gesehen, dass hier gerne mal der Defragmentierer in den Task-Manager gehauen wird und dann täglich läuft. Klingt jetzt nach kinkerlitzchen, aber im jahr macht das konkret 0,1241% der SSD aus. Da ich an meinem Notebook eine CF-Karte über PCMCIA als Festplatte für das system betreibe, welche ein WearLevelingLog anlegt, kann ich weiter gehen, und konkrete daten für den normalverbrauch einer SSD angeben. Bei meiner CF sind dies im Mittel je Sektor 270.000 Schreibzugriffe.
Daraus ergibt sich bei einer MTBF von 5kk eine Lebensdauer der SSD um 18 Jahre mit defragmentieren,
eine Lebensdauer von 19Jahren ohne Defragmentieren.
Die meisten werden jetzt sagen WTF, das eine Jahr, allerdings sind hier ja nur mittelwerte angegeben, und durch das eingebaute Wear-Leveling von SSDs verkürzt sich die Zeit bis zum ersten ausfall mitunter bis auf ein Jahr, allein durch defragmentieren