zurück zur Übersicht
Seit Mac OS X 10.3 Panther werden neu angelegte HFS+ Dateisysteme standardmäßig als journaled Filesystem betrieben. Dies hat zur Folge, daß nach einem Systemabsturz das Dateisystem nicht mehr automatisch vor dem Mounten per fsck auf Fehler geprüft wird, sondern das System dem angelegten Journal blind vertraut.
Dennoch kann ein solcher Check des Dateisystems im single user mode (beim Start 
+ "S" gedrückt halten) sinnvoll sein, um Schäden auch tatsächlich beheben zu können.
Der Check sollte dann mittels
fsck_hfs -y -f -r
durchgeführt werden (ggf. kann man auch noch die Option -d
spendieren, um das Programm ein wenig geschwätziger zu machen).
"Warum muß nach einer Reparatur des Dateisystems dann eigentlich noch einmal neu gebootet werden?"
Es ist Tradition, daß nach einer Reparatur des root fs gebootet wird.
Das liegt daran, daß das Ding bis zum mount -r wie eine Art Notrad mit einem in seiner Intelligenz etwas reduzierten Methode verwaltet wird. Zu dieser Zeit zeigt Dir ein mount etwas der Art / on (root_fs) (ro) weil dem System in diesem Moment nicht ganz klar war, welches device es ist - es hat einfach das genommen, was ihm vom boot
loader in die Hand gedrückt wurde und sich mit Brachialgewalt /kernel, /vmunix, /necronomicon oder sonstwas darauf gesucht.
Bei moderneren Systemen kommt dazu, daß der Kernel aus viel mehr als dieser Datei besteht und irgendwelche Module nachladen muß, um überhaupt zu funktionieren - diese Dateien zu finden und zu laden, bevor die Dateisysteme überhaupt richtig da sind, ist schwarze Magie. Also wird das root fs richtig gemounted - mit allen Caches, die so dazugehören.
Jetzt kommt ein Programm daher, das außerhalb des Kernels abläuft und den Platteninhalt verändert, denn anders kommt man nicht an die Dienstleistung von /sbin/fsck* heran (diese Programme sind praktisch gesehen neue Implementationen der Semantik des betroffenen fs - aber
sie arbeiten nicht über die Kernel-Funktionen zum Zugriff auf strukturierte Verzeichnisdaten sondern greifen blockweise darauf zu).
Ergebnis des Threads, ausgehend von 1gcvs9i.7mhz0q2874r5N%schlu-do@gmx.net.