Re: checksum-fehler - Platte kaputt?

As Jochen Solbrig wrote:

> > > Es gab einen core-dump und FreeBSD st"urzte sofort ab. Na ich
> > Naja, der muß aber einen Grund gehabt haben, der wäre ja interessanter
> > gewesen.
>
> Tja, ich brauchte aber ein verwendbares System, ...

Ich meinte ja, Du hättest den Grund des Coredumps zumindest mal mit
aufschreiben können. Wenn das System in panic gerät, mußt Du doch
nicht deshalb auch gleich in Panik verfallen. ;-)

Vielleicht hatte es ja gar nichts mit der Platte zu tun?

> Aha! In der manpage von bad144 steht aber nichts von initialisieren.

Nur indirekt. Du mußt schon ein ungefähres Vorstellungsvermögen davon
haben, wie die Platten so funktionieren und wo bad144 angesiedelt ist
(nämlich im Treiber, es macht ein remap auf Treiberebene).

> Außerdem dachte ich bad144 wäre dazu da, bad sectors zu lokalisieren.

Kann es ja auch (-s), aber Du mußt erstmal eine leere bad144-Tabelle
anlegen, danach kannst Du dort erst sinnvolle Werte erwarten.

     Bad144 is invoked by giving a device name (e.g. hk0, hp1, etc.).
     With no optional arguments it reads the first sector of the last
     track of the corresponding disk and prints out the bad sector
     information. [...]

Wie bitte soll die Information in den `first sector of last track'
gekommen sein bzw. was passiert, wenn Du die Tabelle nicht
initialisierst? Genau das, was Du gesehen hast: bad144 liest, was es
glaubt der `first sector of last track' zu sein und erzählt Dir das
Ergebnis, egal wie sinnfrei selbiges ist.

> Könnte es denn nicht sein, daß die Magnetisierung in bestimmten
> Bereichen der Platte mit der Zeit "kippt"?

Dann bekommst Du einen CRC-Fehler.

Aber Du hast es trotzdem noch nicht völlig verstanden: sowas handelt
eine IDE-Platte intern ab. bad144 war nötig für Platten, die auch
noch tatsächlich nach außen wie Platten mit Zylindern, Spuren und
Sektoren funktioniert haben, daher meine Referenz, daß ich es zum
letzten Mal bei einer ESDI-Platte benutzt habe. Wenn die IDE-Platte
es intern remappt, kommst Du von außen nicht an diese Daten ran. (*)
Wenn die remap area voll ist, dann ,,siehst'' Du auch außen bad
sectors, dann kannst Du aber eigentlich die Platte auch getrost
wegschmeißen. Ob es dann noch sinnvoll ist, oberhalb welche mit
bad144 auszublenden, ist zweifelhaft -- es werden dann vermutlich
ohnehin täglich mehr werden.

Selbst ESDI konnte man sogar schon mit einem `spare sector per track'
formatieren, den der Controller dann eingesetzt hat für den ersten als
defekt markierten Sektor der Spur. Ja, die Defektmarkierung wurde
damals noch auf der Platte selbst direkt untergebracht, es gab eine
Variante, den kaputten Sektor so zu formatieren, daß bereits im
Sektor-ID-Feld ersichtlich wurde, daß er defekt ist. Davon spricht
die man page von bad144 irgendwo (genauer gesagt davon, daß bad144 das
nicht von selbst erledigt).

bad144 hat also, um's nochmal ganz klar und deutlich zu schreiben,
keinen Einblick in das interne bad sector replacement einer
IDE-Platte.

(*) SCSI hat diese Schnittstelle genormt, dort kann man sich die bad
sector table ansehen, die in der Platte aufgebaut worden ist.

uriah # camcontrol defects da0 -f phys -P
Got 82 defects:
39:0:32
50:2:83
[...]
uriah # camcontrol defects da1 -f phys -P
Got 742 defects:
17:1:153
59:0:4
[...]

Die `grown defect lists' (-G), also was die Platte nach dem letzten
Formatieren zusätzlich im laufenden Betrieb hinzufügen mußte, sind
beide leer, ein gutes Zeichen :). Die Zahlen hab' ich nur mal
geschrieben, damit Du ein Gefühl dafür hast, wie viel bei derartigen
Platten intern bereits in solchen Tabellen steht, ohne daß man es als
Benutzer zur Kenntnis bekommt (da0 ist eine alte Seagate Hawk 2 GB,
da1 eine IBM DCAS 4 GB).

-- 
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message