Es ist nicht notwendig, selbst ein Prebinding durchzuführen. Denn wenn ein Programm gestartet wird, dessen Prebinding-Information nicht aktuell ist, dann wird die Prebinding-Information dieses Programms und all der Libraries (Programm-Bibliotheken), die es verwendet, automatisch aktualisiert.
Hier wird Prebinding gut erklärt.
Ferner sollte man auch nicht selbst eine Defragmentierung vornehmen. Mac OS X defragmentiert selbständig:
Erstens defragmentiert es alle Dateien, die kleiner als 20 MB sind beim Öffnen automatisch (durch die sogenannte On-the-fly Defragmentation). Zusätzliche Bedingungen sind, daß auf der Datei nicht gerade geschrieben wird, sie nicht schreibgeschützt ist, sie mehr als acht Fragmente hat und das System schon drei Minuten läuft.
Und zweitens verschiebt das System die am häufigsten verwendeten Dateien in einen Bereich der Festplatte, wo sie besonders schnell erreicht werden können, wodurch sie ebenfalls defragmentiert werden. Das ist das sogenannte hot file clustering. Dies wird angewendet auf die jeweils 5000 aktuellsten Dateien, die kleiner als 10 MB sind.
Eine Defragmentierung durch den Benutzer kann negative Auswirkungen haben, da manche Methoden das hot file clustering stören. Dann ist der Zugriff auf oft verwendete Daten langsamer.
Auf Dateisystemen des Typs HFS+ ist Defragmentierung unnötig, weil Mac OS X darauf Fragmentierung vermeidet beziehungsweise verhindert:
Dadurch ist Defragmentierung bei dieser Kombination überhaupt nicht notwendig und in den meisten Fällen auch nicht die Mühe wert. Amit Singh hat das mit Praxisbeispielen nachgewiesen.
Er weist ferner darauf hin, daß die Risiken größer als der Nutzen sind: Was passiert bei Stromausfall? Was ist, wenn das Defragmentierungs-Programm einen Fehler hat? Was ist bei einem versehentlichen Neustart? So leicht macht man die Situation durch Defragmentierung nur schlimmer.
Eine manuelle Defragmentierung bringt kaum einen Nutzen seit Mac OS X 10.3 Panther:
Die Firmware moderner Festplatten bildet die vom Betriebssystem angesprochenen logischen Sektoren auf tatsächliche physikalische Sektoren ab (sie macht ein sogenanntes Mapping). Daher kann eine scheinbar defragmentierte Festplatte durchaus fragmentiert sein und umgekehrt, denn auch die Defragmentierungs-Programme kennen nur die logischen Sektoren und allein die Firmware und der Festplattenhersteller kennen das Schema nach dem die Zuordnung von logischen auf physikalische Sektoren vorgenommen wird. Ein Beispiel für diesen Mechanismus ist das Einblenden von heilen Reserve-Sektoren für defekte Sektoren, so daß die Platte intakt erscheint. Dieses Mapping macht jede Defragmentierung absurd.
Von den oben besprochenen fragmentierten Dateien ist jedoch ein fragmentiertes, beschädigtes oder degeneriertes Dateisystem (der Verzeichnisbaum) zu unterscheiden. Dieses kann unter Umständen auftreten und den Rechner behindern. Hier hilft dann, das Dateisystem neu anzulegen entweder durch Formatieren oder durch ein Werkzeug (beispielsweise DiskWarrior), was den Verzeichnisbaum direkt neu erstellen kann. Dieses Risiko sollte man jedoch nur bei einem beschädigten Dateisystem eingehen.
Rechner mit Fusion Drive oder Solid State Disc (SSD) machen Defragmentierung sogar komplett überflüssig, weil da egal ist, wo die Daten liegen, denn es gibt keine mechanischen Teile, insbesondere keinen Schreib-/Lese-Kopf. Defragmentieren ist bei SSDs sogar besonders schädlich, weil das die begrenzte Anzahl an Schreibzyklen pro Speicherzelle unnötig verbraucht.
Viele wissen sicher, daß
Mac OS X täglich, wöchentlich und
monatlich bestimmte Aufgaben automatisch erledigt,
die der Systempflege dienen. Der Fachmann kennt sie
als sogenannte cronjobs
unter diesen Namen:
Diese drei Kommandos starten jeweils Shell-Skripte, deren Inhalt bis 10.5 Leopard diesem Schema folgte:
In 10.5 Leopard rotiert jedoch newsyslog die
Logfiles, was durch den Dämon
com.apple.newsyslog
von launchd periodisch
gestartet wird.
Unix-Maschinen laufen normalerweise rund um die Uhr und werden nie ausgeschaltet. Mit Mac OS X auf Laptops und Home-PCs , die nachts schlafen oder ausgeschaltet sind, kamen nun Rechner hinzu, die zu den normalen Unix -Pflegezeiten nicht laufen.
Den Rechner nachts laufen zu lassen nützt nichts, denn wenn der Mac im Ruhezustand ist (also schläft), werden keine Pflegeaktionen durchgeführt.
Seit 10.4 Tiger werden verpaßte Aufgaben jedoch automatisch nachgeholt, wenn der Rechner irgendwann wieder angeschaltet und wach ist. Dafür sorgt launchd. Siehe dazu auch 2.3.3 Leopard Selbstpflege.
Folglich sammeln sich teilweise enorm große Dateien an, die nie weggeräumt werden und das System suboptimal laufen lassen. Auch werden die Sicherungskopien einiger Systemdateien dann nicht mehr gepflegt. So bemerkt man nach einiger Zeit beispielsweise, daß das Terminal-Programm deutlich länger benötigt beim Starten als normal.
In dem Buch "Mac OS X Panther in a nutshell" vom O'Reilly-Verlag, der bekannt für gute Informatikbücher ist, fand ich auf Seite 350 den Hinweis auf "anacron".
Der anacron
installer
(diese Version ist für alle
Mac OS X-Versionen
vor 10.4 geeignet. Ab 10.4 sollte man die
angepaßte Version nutzen) kommentiert die normalen Pflegezeiten
in
/etc/crontab
für
periodic daily/weekly/monthly
aus und trägt sich selbst ein. Nun wird
anacron
automatisch, wenn der Rechner läuft
(es braucht kein Benutzer eingeloggt sein),
einmal pro Stunde und zwar
jeweils um xx:15 Uhr per cronjob
angestoßen und
schaut nach, ob ein periodic daily
,
periodic weekly
oder periodic monthly
cronjob
verpaßt wurde, in welchem Fall die
versäumten cronjobs
nachgeholt werden.
Anacron wird als
Diskimage heruntergeladen
("anacron.dmg"). Der
DiskImageMounter sollte
als Standard-Programm zum Öffnen angezeigt werden.
Er liegt unter /System/Library/CoreServices/
.
Auf deutsch wird er anders heißen.
Die Vorteile von anacron sind,
daß es
vollautomatisch funktioniert und man sich
nie wieder Sorgen um verpaßte cronjobs
machen
muß, und daß es nicht dauerhaft im Hintergrund
läuft, also kein Dämon ist, und daher keine
Rechenleistung benötigt, außer einmal pro Stunde
ein winziges bißchen.
Die Berichte vom Pflegen kann man sich mit dem Programm "Console" ansehen. Man suche dazu im linken Bereich die Dateien "daily.out", "weekly.out" und "monthly.out".
Hilfsprogramme wie Xupport oder
Onyx hingegen erlauben
das Ausführen der cronjobs
nur manuell,
was nervig ist, da man ja nicht täglich
diese Programme aufrufen möchte. Außerdem sind diese
Hilfsprogramme nicht immer kompatibel zum aktuellen System und
in der Lage das System mit einem Mausklick zu ruinieren.
Mit der Installation von anacron hat man alles getan, was man seit Version 10.2 an Pflege tun kann und sollte. Alles andere ist entweder veraltet oder hat nichts mit Pflege, sondern allenfalls mit Fehlerbehebung zu tun.
Hier ist die Homepage von anacron mit weiterer Dokumentation. Diese Version ist für alle Mac OS X-Versionen vor 10.4 geeignet. Ab 10.4 sollte man die angepaßte Version nutzen.
Tiger selbst verwendet keine cronjobs
mehr, sondern nutzt
einen neuen Mechanismus (launchd
), um verschiedene Dinge zu starten.
Der neue Mechanismus wird über
XML-Dateien
konfiguriert. Cronjobs
können parallel dazu ebenfalls genutzt werden.
Um launchd
zu handhaben, nutzt man im Terminal-Programm
launchctl
. Als Beispiel dazu kann man die periodischen
Wartungsaufgaben auch per Hand aufrufen mit:
Der neue Mechanismus hatte anfangs dasselbe Problem wie der alte: Wenn der Rechner schläft, dann laufen die Pflegeaktivitäten nicht und werden auch nicht nachgeholt. Daher war anacron immer noch nützlich.
Es gibt eine speziell
für 10.4 angepaßte Version von
anacron, die launchd
anstatt
cronjobs
verwendet.
Sobald launchd
wie von Apple geplant funktioniert, braucht man
anacron nicht mehr. Allerdings scheint launchd
noch nicht soweit zu sein.
Ein Fehler in 10.4. und 10.4.1 ist in launchd
noch nicht behoben,
der sich darin zeigt, daß kalendarabhängige Aufgaben zu
unerwarteten Zeiten laufen.
Die Version 10.4.2 soll die periodischen Aufräumarbeiten nun mit
launchd
laufen lassen, wie im Zeitplan eingetragen laut Apples
Beschreibung.
Die Version 10.4.3 läßt die drei Arten von Wartungen tatsächlich selbständig laufen auch ohne anacron.
Hier ist ein Shell Script
von mir, das anacron (die Tigerversion)
komplett entfernt. Man kann dann probieren, ob es inzwischen ohne anacron
klappt.
Es basiert auf der Dokumentation (ist enthalten im Archiv)
zu anacron
für 10.4. Man kann es einfach auf das Terminal-Programm ziehen,
um es zu starten, oder per Doppelklick oder natürlich auch direkt im
Terminal: Dazu das entpackte Skript ins Benutzerverzeichnis legen
und mit ./removeanacron.sh
starten.
In der Systemversion 10.5 laufen die Wartungsaufaben zuverlässig und regelmäßig selbst bei Rechnern, die nur sporadisch genutzt werden. Daher ist Anacron nun überflüssig. Zusammenfassend gilt: Leopard pflegt sich allein und Eingriffe des Benutzers wirken sich in der Regel negativ aus.