ich hoffe jemand hat eine Idee:
Es handelt sich um mein MacBook2,1 Core 2 Duo 2GHz, 3 GB Ram, 500 GB Samsung HM500LI. Heute morgen ist mir das Book zweimal eingefroren, nix ging mehr. Dann hab ich ganz normal den Ausknopf benutzt um ihn wieder hochzufahren und nach einem normalen Bootvorgang das Festplattendienstprogramm bemüht, um mal nach Fehlern zu suchen.
Und siehe da: Bei Volume prüfen meiner Mac-Partition hieß es zuerst “Falsche Threadanzahl” - Volume muß repariert werden.
Ich hab das FDP dann nochmal das Volume prüfen lassen, dann hieß es “Falsche Blockanzahl in Datei Cache.003” Volume muß repariert werden.
Also hab ich meine Leopard-DVD rausgekramt (ich hoffe man muß dazu nicht die grauen Scheiben nutzen, die original beim Book dabei waren??) und habe das FDP von der Disk gestartet und das Volume reparieren wollen. Dann hieß es aber das Volume sei wohl in Ordnung und müsse nicht repariert werden.
Was sagt mir das nun? Muß ich mir Sorgen um die interne Platte machen?
ich habe den Check nach “Volume prüfen” und einmal Rechte reparieren in dieser Reihenfolge laufen lassen. Da kam dann in beiden Fällen, daß alles ok wäre.
Ich vermute mal, daß er das schon überprüft hat, aber was das FPD genau treibt, keine Ahnung…
Ich hab gerade nochmal das FDP von der DVD laufen lassen - und siehe da da waren zwei verwaiste Datei-Inodes, die nun unter lost & found auftauchen. Ist das bedenklich? Vorher sagte das FDP es hätte ne falsche Anzahl von Datei-Hardlinks erkannt.
Hardlinks und i-nodes gehören zusammen und machen eine Datei aus.
[klugschissmode]
Die folgenden Informationen beziehen sich auf UFS, sollten aber für alle unixoiden Filesysteme weitestgehend stimmen.
Eine Datei besteht aus einem Eintrag in einer Directorydatei (bestehend aus dem Namen der Datei und einer i-node Nummer, wenn es mehrere davon gibt, dann nennt man die weiteren Hardlinks), eben einer i-node mit allen ihren Verwaltungsinformationen, unter anderem Verweisen auf Datenblöcke und wenn eine Datei auch einen Inhalt hat, dann eben auch Datenblöcken (die auch noch über die Free-Block-List im Filesystem verwaltet werden). Wenn es wie oben schon erwähnt einen oder mehrere Hardlinks auf eine i-node gibt, dann spiegelt sich diese Anzahl im Feld Linkcount in der i-node wieder. Wird nun eine Datei gelöscht, dann wird aus der Directorydatei der entsprechende Eintrag gelöscht, der Linkcount in der i-node um 1 reduziert und überprüft, ob der Linkcount 0 ist. Wenn nein, dann keine weitere Aktion, wenn ja, dann wird die i-node zum Überschreiben freigegeben und die allokierten Blöcke in der Free-Block-List als frei markiert.
Das Journaling von HSF+ sollte nun eigentlich dafür sorgen, dass diese Informationen stets konsistent sind. In deinem Fall kann es nun passiert sein, dass zwei solche Einträge in Directorydateien verschütt gegangen sind, aber die Linkcounts in den i-nodes nicht berichtigt wurden. Dann haben wir den Fall dass der Linkcount 0 sein sollte, aber auf 1 steht. In dem Fall erstellt fsck im Verzeichnis lost+found einen Directorydatei Eintrag mit der Syntax #inodenummer und verweist auf die entsprechenden i-nodes. Man stellt sich dabei auf die sichere Seite, im schlimmsten Fall leben gelöschte Dateien halt weiter. Schau mal, ob du anhand des Inhaltes der Dateien rausfinden kannst wer die mal waren.
[/klugschissmode]
es sind zwei FLV-Videos… einmal Gerhard Polt und noch was anderes. Die laufen sogar noch. Muß ich mir da jetzt Gedanken um die Gesundheit der Platte machen, oder sind das einfach HFS±Schwächen??
Einfach so sollte so was nicht passieren. Gab es in letzter Zeit mal einen Crash oder wurde die Maschine mal ungeplant vom Strom befreit?
Wenn es eine bekannte Schwäche von HFS+ wäre, dann hätten das auch andere und vor allem würden die Alarmglocken bei Apple in Cupertino so laut schrillen, dass wir das hier in D-Land hören könnten.
An ein Hardware Fehler würde ich jetzt mal nicht glauben. Hast du ein Programm mit dem du einen Oberflächentest durchführen kannst?
)