Kann es sein das es unter OS X kein “bad block replacement” gibt
Ich werde mit folgender Fehlermeldung konfrontiert:
16.06.08 07:50:29 /System/Library/CoreServices/backupd[740] Error: (-36) copying /Users/xxx/Library/Application Support/Firefox/Profiles/xxxxxxx.default/urlclassifier2.sqlite to (null)
Na, gut, ist die Datei halt kaputt. Techtool Deluxe findet beim Oberflächen Test den Fehler auch und schlägt lapidar vor, die Platte zu sichern, neu formatieren und gut ist es
Hä, kann es das wirklich sein dass ich die Platte neu formatieren muss? Bei heimischen Systemen hatte ich so einen Fehler schon ewig nicht mehr, bei Solaris bin ich es gewöhnt dass sich das System selber drum kümmert wenn es die Datei noch lesen kann und wenn nicht, dann weg damit, zurück vom Backup aber nicht formatieren.
Sind die Fehlermeldungen von TechTool immer noch auf Mac OS 9-Niveau? Bad Block Replacement soll doch beim „Volume reparieren“ durchgeführt werden (Festplattendienstprogramm), steht dann auch im Log.
DVD Boot und Volume reparieren war nix.
Ohne Oberflächentest, woher soll er wissen welche Blöcke betroffen sind.
Somit wird aber auch neu formatieren nichts helfen, da er dort ja nur die Filesytem Struktur neu anlegt, aber keinen Oberflächentest macht.
Hm, wenn sonst keine weiteren Ideen kommen, dann werde ich mal einen Call bei Apple eröffnen.
Nanu? Moment, muss mal was nachschlagen (gab eine Anleitung zur Lösung mit Terminal in einer Macwelt/MacUp Ausgabe). Wenn es kosten darf macintosh-data-recovery.com/ … atures.php (es gibt eine Testversion, ob die aber bad block replacement durchführt, weiss ich nicht)
Danke für die Hinweise, aber > 100 Flocken - “die spinnen die Römer”
Eine CLI-Lösung wäre auch was feines…
Ich werde mal einen Call bei Apple aufmachen, die Maschine ist ja noch keine 2 Wochen alt, da will ich nicht schon defekte Blöcke haben.
Mal schauen was die so sagen.
Ich weiss nicht, wie sich das Programm weiterentwickelt hat (eigentlich Backup Lösung) bacula.org gibt/gab es für Mac OS X 10.1 (da war CLI Lösungen noch nötig), ich suche noch weiter, da war noch eine andere Lösung…
Einen Call bei Apple zu öffnen war auch irgend wie ein Kalter
Anruf - Von dem Mitarbeiter ferngesteuert von DVD booten und HW-Test machen, wenn kein Fehler gemeldet wird, dann den Fehler durch lesen der defekten Datei noch mal produzieren und über Systemprofiler - Ablage - An Apple senden die Infos einschicken, da soll dann auch das system.log dabei sein, da sieht dann beim nächsten Anruf der Bearbeiter den Fehler. - Ende des Gesprächs.
Natürlich wurde kein Fehler gefunden (findet sich wie von mir prophezeit auch nur bei einem Oberflächentest der mehrere Stunden dauert)
Also die Infos an Apple geschickt und
Anruf - Call-ID angegeben - Um was geht es? - Noch mal alles erklärt. - Was haben sie eingeschickt? - Na das Zeugs vom Systemprofiler… - Such, such, such, ah hier sind die Daten, da steht nix von IO-Error drin. Welche Datei ist kaputt? - Ist doch Banane, es ist ein fehlerhafter Block auf der Platte, wie uns das TechTool sagt - Ja wenn sie das mit TechTool feststellen, dann ist das kein Beweis - Wie? Warum wird dann das Teil von Apple mit dem Apple Care mit geschickt? - Das ist keine SW von Apple, das interessiert uns nicht Bringen sie den Rechner zu einem Service Provider und lassen sie die Platte prüfen. Wenn sie kaputt ist wird die Platte getauscht. - Darf ich die Platte vorher löschen? - Warum? - Na was gehen das Servicecenter meine Daten an? - Denen können Sie schon vertrauen. - Und wenn die Platte kaputt ist und getauscht wird, dann wandern meine Daten zum Plattenhersteller, das kann doch nicht sein! - Na gut, dann können Sie die Platte löschen. - Ende des Gesprächs.
Tolle Rolle, so stelle ich mir einen Qualifizierten Helpdesk vor :shoot:
Na gut, dann werde ich meine Daten wieder auf das MB zurück ziehen, den iMac plätten und mal schauen wie lange die Kiste bei Gravis sein wird
Das sind ja keine guten Nachrichten… Ich habe jetzt mal einige alte Zeitschriften zu diesem Thema durchforstet (Die CLI-Lösung war wohl vor 2006). Ich fürchte, das ich „Bad Block Replacement“ mit „Self-Monitoring Analysis and Reporting Technology“ (kurz S.M.A.R.T.) verwechselt habe - wäre ja schön wenn da auch „Bad Block Replacement“ Einzug halten würde, aber so weit sind die HD-Hersteller wohl noch nicht… (bieten die keine Test-Tools für Mac an?)
Das Problem ist, dass das Bad Block Replacement auf verschiedenen Ebenen stattfindet.
Der unterste Level ist in den Platten selber. Die haben Reserve Blöcke und wenn irgend wo auf der Platte ein Fehler auftritt dann wird der Fehler Block auf so einen Sapare Block verlager. In der Regel ist hier auch ein Korrektur der Daten möglich. Von dem bekommt das OS gar nichts mit. Stati dazu kann das OS per S.M.A.R.T. von der Platte erfragen. Schwieriger wird es, wenn so was nach oben durchschlägt. Das passiert dann, wenn der Platte die Spare-Blocks ausgehen, dann ist das Teil aber definitiv ein Fall für die Tonne, oder die Korrektur der Daten ist nicht möglich. Hier ist dann die Strategie des OS gefragt. Ein Dateisystem hält sich auch Spare-Blocks (kann man bei newfs auch für HFS+ parametrisieren) für so was frei.
Was ich seltsam finde, ist dass OS X hier nichts in irgend einem Logfile hinterlässt. In meinem Fall hat der backupd ganz lapidar einen Fehler gemeldet. Hallo, ein defekter Block im Filesystem ist ein heftiges Ereignis, da darf der Kernel ruhig ganz laut in das Logfile reinschreien. Blöd ist eben auch dass es kein Kommando gibt das einen Oberflächentest mit Block Replacement macht (weder fsck, noch pdisk noch newfs). Solaris hat da z.B. in seinem Format Kommando eine Option mit der man die Platte testen kann und auch ein Bad Block Replacement erzwingen.
Ups, was habe ich da eben bei meinen Forschungen im Web festgestellt - ZFS hat es zwar nicht in Leopard geschafft, aber DTrace
Nee, so schlimm ist es nicht.
Gravis wird sicher einen Fehler auf der Disk finden und selbige tauschen (ist auch im meinem Sinne da eine Platte die einmal muckt weg muss).
Nur eben schade dass OS X hier eher wenige Reparatur-/Diagnosemöglichkeiten bietet.
So ein Ereignis sollte auch über S.M.A.R.T. sichtbar sein.
Dem Sinn von ZFS steht bei den meisten Apple Rechnern die eine einzige Platte im Weg.
Das kann seine Vorteile dort ausspielen wo es möglichst viele, möglichst dumme Platten gibt