Wie willst du sowas vermeiden? Bei vielen Dateien ist im vorhinein nicht klar wie groß sie werden (mp3, oder Logfiles z.B.) Um dort eine fragmentierung zu vermeiden, müsste jeder Datei beim sichern erstmal präventiv ein 4GB Block zugeordnet werden. Da möchte ich dich sehen, wenn dein Rechner das speichern verweigert wenn zwar noch 120GB auf der Platte frei sind, aber eben kein einziger kompletter 4GB Block.
Das OS X Filesystem ist immerhin so clever, das es beim überschreiben von Dateien prüft, in wieviel Fragmente die Datei zerlegt ist, und sie bei mehr als 8 Teilen dann komplett neu am Stück schreibt. Neue Dateien werden Grundsätzlich nur dann in mehrere Teile zerlegt, wenn kein freies Einzelstück vorhanden ist. Wenn man das konsequent durchhält, kommt es eigentlich erst zu fragmentierungen, gegen Ende der Plattenkapazität. Und die alte Regel Platten nicht mehr als bis zu 90-95% zu füllen gilt m.E. nach wie vor.
Aber eben nicht, wenn man beim schreiben schon drauf achtet, das sie am Stück hinten an den bereits belegten Platz geschrieben werden. bzw. in entstandene Lücken bereits gelöschter Daten. Aber eben immer unter der Prämisse: Am Stück! Das führt dann zwar zu unbelegten Löchern, aber eben nur sehr kleine, in die quasi nichts reinpasst, was so täglich anfällt (und das Unix Filesystem macht Haufenweise gebrauch von 0Byte großen Dateien, wo über deren reines Vorhandensein z.B. ein Parameter gesetzt wird.
Was aber letztendlich nicht an die Eleganz und Effizienzen an die grundsätzlichen Überlegungen des HFS+ nicht heranreicht (Das ist aber nicht auf Apples Mist gewachsen, solche features hatten Systeme wie Novell schon in den 80er Jahren implementiert, wie z.B: auch die inzwischen recht weit verbreitete Suballocation. Dabei werden Kleinstdateien in Container verpackt, die die minimale Sektorgröße und damit kleinstmögliche ansprechbare Plattenplatz belegen und dorthinein wiederum, für den Nutzer _und_ System völlig unbemerkt, zig Kleinstdateien von einigen Bytes Größe ablegen. sondern nur Schadensbegrenzung bedeutet. Damit hat sich aber auch unauffällig die alte Frage erledigt: Große Sektoren = Schnell, aber wenig Dateien, kleine Sektoren =Viele Dateien aber langsam. Das Bekommt aber keiner Mit und den Usern werden seit Jahren für mehr oder weniger viel Geld Tools untergejubelt die eigentlich nichts mehr zu tun haben, weil sie an diese Containerdateien überhaupt nicht mehr drankommen.)
Das Stichwort ist 'vernünftig' Man kann diese Tools zwar kaufen, aber mit 'Vernünftig hat das nicht unbedingt zu tun.
Allein der Vorgang der Defragmentierung ist doch dafür schon ein Musterbeispiel:
Kein, wirklich kein Hersteller von Defrag Tools schrreibt nicht Ausdrücklich vor, vor der Defragmentierung ein Backup anzufertigen. Das nciht zu unrecht, denn bei der direkten Defragmentierung wird das System in einen äusserst labilen Zustand versetzt, weil es quasi 2 Zuordnungstabellen gibt, eine Alte und eine entstehende Alte und jede Bewegte und wieder verineinheitlichte Datei wird sukzessive vom einen in den anderen Eintrag eingetragen und aussortiert. Sprich beide sind nicht wirklich das was sie sein sollten: Absolut eindeutig.
Nun Versuch man also, ein oder 2 Dateien des Systems, die einfach durch die Fehlerträchtigkeit, die ja auch einem Computer innewohnt, wieder gangbar zu machen, indem man mit hundertausenden von Einträgen genau das macht, was diese Fehler mal hervorgerufen hat: Speichern irgendwohin, und eben nicht korrekt nachhalten wo es gelandet ist.
Wenn das nicht an den Teufel mit dem Belzebub austreiben erinnert, weiss ich's auch nicht.
Und zu guter letzt: Backup + Defragmentierungsaufwand ist nur unwesentlich kleiner einem Platteninhalt komplett backuppen, Quellplatte löschen und alles zurückspielen.
Das hat alles mehr mit Voodoo zu tun, als mit wirklicher Systempflege
als Antwort auf: [#249694]