2. Automatisches Pflegen Inhaltsverzeichnis

Stichwort-Liste

2.1 Kein Prebinding von Hand notwendig

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.

2.2 Keine Defragmentierung von Hand notwendig

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.

SSDs und Fusion Drive

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.

2.3 Periodische Skripte

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:

  1. Bestimmte alte Dateien (in der Regel sind das Logfiles) wegräumen.
  2. Andere Skripte aufgerufen, die Sicherungskopien von verschiedenen Systemdateien anlegen.
  3. Weitere Skripte aufgerufen, die einige nützliche Hilfsprogramme starten.

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.

2.3.1 Anacron für 10.4 und launchd

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.

2.3.2 Praktische Mängel

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.

2.3.3 Anacron entfernen

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.

2.3.3 Leopard Selbstpflege

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.

Valid XHTML 1.0!

Besucherzähler


Latest Update: 11. September 2015 at 19:51h (german time)
Link: www.macmark.de/osx_auto-clean.php