Re: Problem mit badblocks
Hallo Marc,
ich habe mit "badblocks" festgestellt das ich eben diese auf einer meiner Platten habe. Am Besten, du sicherst alle daten der Platte und buegelst dann ein neues FS drueber unter Beruecksichtigung der badblocks. Ich weiss dass das mit ext2 geht. Siehe manpage. Da es sich um eine BachupPlatte handelt habe ich mit yast1 diese ein neues ext2 FS gespendet. Dann habe ich mit e2fsck -c -p /dev/hdb1 versucht die badblocks loszuwerden. Aber es hat wohl nicht geholfen. Vielleicht habe ich ja Knoepfe auf den Augen aber ich find keine besseren Optionen in den man pages. Kann mir jemand helfen die badblocks unschaedlich zu machen.
Vielen Dank jeder Tipp ist willkommen. Michael
* Michael Hoeller schrieb am 18.11.01 um 09:41 Uhr:
Hallo Marc,
ich habe mit "badblocks" festgestellt das ich eben diese auf einer meiner Platten habe. Am Besten, du sicherst alle daten der Platte und buegelst dann ein neues FS drueber unter Beruecksichtigung der badblocks. Ich weiss dass das mit ext2 geht. Siehe manpage. Da es sich um eine BachupPlatte handelt habe ich mit yast1 diese ein neues ext2 FS gespendet. Dann habe ich mit e2fsck -c -p /dev/hdb1 versucht die badblocks loszuwerden. Aber es hat wohl nicht geholfen. Vielleicht habe ich ja Knoepfe auf den Augen aber ich find keine besseren Optionen in den man pages. Kann mir jemand helfen die badblocks unschaedlich zu machen.
Wenn du Pech hast, kommen jetzt staendig neue Badblocks dazu. Wenn eine Platte badblocks hat, ist das meistens ein Zeichen, dass sie bald ganz den Geist aufgibt. Ich hatte in meinem Fall anscheinend ziemliches Glueck gehabt. Was ext2 angeht. Wenn du schon ein neues FS erzeugst, dann kannst du ihm die Liste der badblocks auch gleich als Datei uebergeben. Mach doch einfach nochmal ein badblocks auf die Platte und speichere die Ausgabe in eine Datei (-o wars glaub ich) Und dann nimmst du mke2fs und uebergibts ihm diese Liste. Dabei musst du darauf achten, dass du bei beiden Kommandos auch die gleichen Blockgroessen verwendest. -Marc -- BUGS My programs never have bugs. They just develop random features. If you discover such a feature and you want it to be removed: please send an email to bug@links2linux.de
Hallo,
From: "Marc Schiffbauer"
Wenn du Pech hast, kommen jetzt staendig neue Badblocks dazu.
...oder so. So "richtig" nutzen würde ich die Platte auch nicht mehr. Ich hatte hier zwar mehrere Platten, die fast neu (Also Garantiezeit + viertelstunde :-) ) Badblocks hatten und danach noch jahrelang funktioniert haben - aber sowas setze ich nur in Bastelsystemen oder als MP3-Grab-Platte oder dergleichen ein. Ich mache das dann immer so, daß ich um die Badblocks herum großräumig auspartitioniere. Also, Beispiel: 8 GB-Platte, Fehler bei 3 GB: 1. Partition 2,7 GB mit Filesystem 2. Partition 2,7-3,3 GB, enthält den Fehler, kein Filesystem 3. Partitition, 3,3 GB bis Ende, mit Filesystem Bisher ist es mir noch nicht passiert, daß eine kaputte Platte auch an ganz anderer Stelle pellt. Was nicht heisst, daß es nicht passieren kann. Gruß, Ratti
On Sun, Nov 18, 2001 at 02:55:17PM +0100, Ratti wrote:
Hallo,
From: "Marc Schiffbauer"
Wenn du Pech hast, kommen jetzt staendig neue Badblocks dazu.
...oder so. So "richtig" nutzen würde ich die Platte auch nicht mehr.
Ich hatte hier zwar mehrere Platten, die fast neu (Also Garantiezeit + viertelstunde :-) ) Badblocks hatten und danach noch jahrelang funktioniert haben - aber sowas setze ich nur in Bastelsystemen oder als MP3-Grab-Platte oder dergleichen ein.
Jede Platte hat AFIAK ab Werk bad blocks. Deshalb befindet sich auch eine "bad blocks table" auf dem Gehäuse. Dafür gibt es dann einen Grenzwert. Wo der allerdings liegt kann ich auch nicht sagen. -- Gruß Alex
Hallo,
From: "Alex Klein"
Jede Platte hat AFIAK ab Werk bad blocks. Deshalb befindet sich auch eine "bad blocks table" auf dem Gehäuse. Dafür gibt es dann einen Grenzwert. Wo der allerdings liegt kann ich auch nicht sagen.
Das betrifft aber nicht den normalen Einsatz von Platten. Eine normal formatierte Platte darf nicht plötzlich Daten verlieren. War diese Ausmaskierung nicht sowieso nur für SCSI? Und auf Plattenbios-Ebene? Gruß, Ratti
On Sun, 18 Nov 2001 18:15:11 +0100, Ratti wrote:
Hallo,
From: "Alex Klein"
Jede Platte hat AFIAK ab Werk bad blocks. Deshalb befindet sich auch eine "bad blocks table" auf dem Gehäuse. Dafür gibt es dann einen Grenzwert. Wo der allerdings liegt kann ich auch nicht sagen.
Das betrifft aber nicht den normalen Einsatz von Platten. Eine normal formatierte Platte darf nicht plötzlich Daten verlieren.
War diese Ausmaskierung nicht sowieso nur für SCSI? Und auf Plattenbios-Ebene?
Wieso sollte das nur SCSI Platten betreffen? Jeder Plattenhersteller hat doch dafür Programme um sowas auszubügeln. It's time to close windows !!! with best regards from Dortmund Matthias Popp 49-163-4289 455 PGP Public Key Fingerprint = 71 13 E9 4B 89 E5 88 6C 66 1D B8 E8 32 3A AE AB
On Sun, 18 Nov 2001, Ratti wrote:
From: "Alex Klein"
Jede Platte hat AFIAK ab Werk bad blocks. [..] Das betrifft aber nicht den normalen Einsatz von Platten. Eine normal formatierte Platte darf nicht plötzlich Daten verlieren.
Ja.
War diese Ausmaskierung nicht sowieso nur für SCSI? Und auf Plattenbios-Ebene?
Nein. Ja. Genauer (zumindest fuer IDE-Platten juenger als ca. 6 Jahre): Die Platte hat intern einen "reservierten Bereich" von Sektoren, in den die Firmware der HD defekte Sektoren umbiegt. Von diesem Vorgang (Remapping von defekten Sektoren) bekommt weder der IDE- Controller, geschweige den das OS etwas mit. Hoechstens anhand des Symptoms "Datei ist (angeblich) nicht fragmentiert -- aber beim Zugriff ist die Platte froehlich am 'seeken'" kann man das erkennen. Ausser man verwendet ein spezielles Tool, das die Firmware nach dem Status dieses Bereichs befragt, wobei man da IIRC nur das Tool der jew. HD-Herstellers verwenden kann -- so es denn ein solches gibt. Wenn dann "beim OS" defekte Sektoren "ankommen" heisst das also, dass der "Reserve-Bereich" voll ist, d.h. die Platte hat schon X Sektoren verloren... Mit einem sog. Low-Level-Format laesst sich je nach HD evtl. der Status der "Bad-blocks" zuruecksetzen, aber das kaschiert nur die Symptome (bad-blocks). Fazit: einer HD die defekte Sektoren meldet sollte man nicht weiter trauen, als man einen Blauwal werfen kann. -dnh -- "Now, what was I doing before I so rudely interrupted myself?"
Moin,
War diese Ausmaskierung nicht sowieso nur für SCSI? Und auf Plattenbios-Ebene?
From: "David Haller"
Nein. Ja. Genauer (zumindest fuer IDE-Platten juenger als ca. 6 Jahre):
OK. Dann kann IDE das also inzwischen auch. Kinder, wie die Zeit vergeht. ;-)
Die Platte hat intern einen "reservierten Bereich" von Sektoren, in den die Firmware der HD defekte Sektoren umbiegt.
Das hiesse: Von vornherein defekte Sektoren werden beim Formatieren erkannt und ausgemappt. Tauchen später neue defekte auf, wird ein Schaden größer - analog einem Schlagloch in der Straße. Diese Blocks werden mit Reserveblocks ausgemappt. Erst, wenn die Reserve aufgebraucht ist, bekommt man auf "normaler" Applikationsebene den Schaden überhaupt mit. Ist das so richtig? Dann verstehe ich eins nicht: Wenn ein Block kaputt geht, aber noch ausgemappt werden kann - dann müssten die Daten ja futsch sein (Block kaputt), bei Kontrolle aber kein Fehler zu finden sein (ist ja ausgemappt). Meiner Erfahrung nach passiert das so aber nicht: Sich als "Heile" identifizierende Platten verlieren keine Daten, und erst, wenn die Platte Geräusche macht oder hängenbleibt, sind wirklich Daten futsch. Kann das jemand erklären? Zweiter Punkt: Hier wurde behauptet, die lange Zahlenliste auf der Platte sei eine Liste der defekten Sektoren. Ich hätte es ja nicht nachgeprüft, aber da ich heute sowieso eine Platte in einen G4 eingebaut habe... ähm... die lange Zahlenliste sind US-Patente. Keine bad blocks. ;-) Gruß, Ratti
On Mon, 19 Nov 2001, Ratti wrote:
War diese Ausmaskierung nicht sowieso nur für SCSI? Und auf Plattenbios-Ebene?
From: "David Haller"
Nein. Ja. Genauer (zumindest fuer IDE-Platten juenger als ca. 6 Jahre):
OK. Dann kann IDE das also inzwischen auch. Kinder, wie die Zeit vergeht. ;-)
;-(
Die Platte hat intern einen "reservierten Bereich" von Sektoren, in den die Firmware der HD defekte Sektoren umbiegt.
Das hiesse: Von vornherein defekte Sektoren werden beim Formatieren erkannt und ausgemappt. Tauchen später neue defekte auf, wird ein Schaden größer - analog einem Schlagloch in der Straße. Diese Blocks werden mit Reserveblocks ausgemappt. Erst, wenn die Reserve aufgebraucht ist, bekommt man auf "normaler" Applikationsebene den Schaden überhaupt mit.
Ist das so richtig?
Nein. Erst wenn die Reserve aufgebraucht ist koennen beim formatieren defekte Sektoren erkannt werden -- vorher "luegt" die HD darueber, dass ein Sektor "klammheimlich" schon in den Reservebereich "verlegt" wurde... d.h. egal von was (also auch fdisk/mkfs.* oder scandisk) defekte Sektoren gemeldet werden, _wenn_ defekte Sektoren gemeldet werden, dann wurde die Reserve schon aufgebraucht.
Dann verstehe ich eins nicht: Wenn ein Block kaputt geht, aber noch ausgemappt werden kann - dann müssten die Daten ja futsch sein (Block kaputt), bei Kontrolle aber kein Fehler zu finden sein (ist ja ausgemappt).
Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen (durch mehrfache Leseversuche, die dann "gemittelt" werden und das wahrscheinlichste Ergebnis wird dann verwendet) und auf einen der Reservesektoren kopieren. Die Defekte sind mehr oder weniger schleichend, und je nachdem welche Toleranz in der Firmware eingestellt wurde, wird frueher oder spaeter ein Sektor als "defekt" betrachtet (und in die Reserve verlagert). Von all dem bekommt _keine_ Software ausser der Firmware der HD etwas mit -- auch nicht das BIOS oder ein mkfs/badblocks -- diese bekommen _erst_ etwas mit, wenn die Reserve aufgebraucht ist. Allerdings gibt es IIRC spezielle Firmwarefunktionen und Software des Herstellers, mit dem die HD-Firmware nach dem Status des Reservebereichs befragt werden kann.
Meiner Erfahrung nach passiert das so aber nicht: Sich als "Heile" identifizierende Platten verlieren keine Daten,
Doch -- allerdings nicht "von jetzt auf nachher", sondern schleichend, und somit kann die Firmware die Daten noch in einen Reservesektor kopieren.
und erst, wenn die Platte Geräusche macht oder hängenbleibt, sind wirklich Daten futsch.
Das ist dann der "GAU" ;)
Kann das jemand erklären?
Ja. Der schleichende Verlust wird eben eine Weile durch die Reserve "versteckt"...
Zweiter Punkt: Hier wurde behauptet, die lange Zahlenliste auf der Platte sei eine Liste der defekten Sektoren. Ich hätte es ja nicht nachgeprüft, aber da ich heute sowieso eine Platte in einen G4 eingebaut habe... ähm... die lange Zahlenliste sind US-Patente. Keine bad blocks. ;-)
Haette mich auch gewundert ;) An "Daten" findet man ueblicherweise nur das logische CHS-Mapping[1], das die HD ans BIOS weitergibt und die Jumperbelegung (sowie vielleicht noch irgendwelche elektrischen Daten)... -dnh [1] physikalisch haben HDs heute ja meist 1-8 Koepfe. Bei Maxtor sieht man das z.B. an der Endziffer der Modellbezeichnung, z.B. ein H8 heisst, dass 4 Scheiben \`a 2 Koepfen der HD rotieren... Ergo ist selbst eine logische Geometrie x/16/y "gelogen" -- aber die Umsetzung macht die HD-Firmware, und nicht der IDE-Controller oder gar das BIOS... # for i in a b c; do cat /proc/ide/hd${i}/{model,geometry}; done Maxtor 91303D6 physical 25249/16/63 logical 1584/255/63 real: 6 Koepfe auf 3 Scheiben und gut 2 GB / Oberflaeche Maxtor 92041U4 physical 39703/16/63 logical 2491/255/63 real: 4 Koepfe auf 2 Scheiben und gut 4.7 GB / Oberflaeche IBM-DTLA-305040 physical 19710/16/255 logical 5005/255/63 real: weiss grad nicht... 4, 5, 6 oder 8? ;) Das "physical" ist die Geometrie, die die HD meldet, wenn sie befragt wird, und die i.d.R. auch auf dem Plattenlabel steht, "logical" ist die, die im BIOS eingestellt wird (normal/CHS/LBA). -- 6: Globale Variable Parameterübergabemechanismus in 4GLs (Marit Köhntopp)
Hi David On Tue, Nov 20, 2001 at 01:00:15AM +0100, David Haller wrote:
On Mon, 19 Nov 2001, Ratti wrote:
OK. Dann kann IDE das also inzwischen auch. Kinder, wie die Zeit vergeht. ;-)
;-(
ja es ist erschreckend wie lange es gebraucht hat bis sich ein gutes Konzept verbreitet hat und noch erschreckender ist es das man das Interface was es bei SCSI dafür gibt nicht mit portiert hat. :-/
Erst wenn die Reserve aufgebraucht ist koennen beim formatieren defekte Sektoren erkannt werden -- vorher "luegt" die HD darueber, dass ein Sektor "klammheimlich" schon in den Reservebereich "verlegt" wurde...
d.h. egal von was (also auch fdisk/mkfs.* oder scandisk) defekte Sektoren gemeldet werden, _wenn_ defekte Sektoren gemeldet werden, dann wurde die Reserve schon aufgebraucht.
Ack
Dann verstehe ich eins nicht: Wenn ein Block kaputt geht, aber noch ausgemappt werden kann - dann müssten die Daten ja futsch sein (Block kaputt), bei Kontrolle aber kein Fehler zu finden sein (ist ja ausgemappt).
Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen (durch mehrfache Leseversuche, die dann "gemittelt" werden und das wahrscheinlichste Ergebnis wird dann verwendet) und auf einen der Reservesektoren kopieren. Die Defekte sind mehr oder weniger schleichend, und je nachdem welche Toleranz in der Firmware eingestellt wurde, wird frueher oder spaeter ein Sektor als "defekt" betrachtet (und in die Reserve verlagert). Von all dem bekommt _keine_ Software ausser der Firmware der HD etwas mit -- auch nicht das BIOS oder ein mkfs/badblocks -- diese bekommen _erst_ etwas mit, wenn die Reserve aufgebraucht ist.
hier wird auch teilweise einfach beim schreiben mit dem writecache gegengecheckt, ausserdem gibt es prüfsummen über die internen Sektoren deren Grösse genau gar nichts mit dem zu tun hat was die Platte nach aussen hin zeigt.
Allerdings gibt es IIRC spezielle Firmwarefunktionen und Software des Herstellers, mit dem die HD-Firmware nach dem Status des Reservebereichs befragt werden kann.
so man ein passendes tool findet, die Halbwertszeit dieser Programme ist atemberaubend kurz.
Meiner Erfahrung nach passiert das so aber nicht: Sich als "Heile" identifizierende Platten verlieren keine Daten,
Doch -- allerdings nicht "von jetzt auf nachher", sondern schleichend, und somit kann die Firmware die Daten noch in einen Reservesektor kopieren.
vor allem 'merken' es viele Platten erst beim schreiben und das ist das eigentliche Problem.
Ja. Der schleichende Verlust wird eben eine Weile durch die Reserve "versteckt"...
und man hat on the fly bei IDE/ATA idr. keine Chance mal eben die 'Grown defekt list' auszulesen und geeignete Massnahmen einzuleiten wie bei SCSI.
Zweiter Punkt: Hier wurde behauptet, die lange Zahlenliste auf der Platte sei eine Liste der defekten Sektoren. Ich hätte es ja nicht nachgeprüft, aber da ich heute sowieso eine Platte in einen G4 eingebaut habe... ähm... die lange Zahlenliste sind US-Patente. Keine bad blocks. ;-)
Haette mich auch gewundert ;)
auf den guten alten SCSI Platten war das so, allerdings hab ich das noch bei keiner IDE/ATA Platte gesehen und ich hab schon viele gesehen - in letzter Zeit leider zu viele, viel zu oft. :-/ -- MfG. Falk
Am 20-Nov-2001 Falk Sauer schrieb:
Hi David
On Tue, Nov 20, 2001 at 01:00:15AM +0100, David Haller wrote:
On Mon, 19 Nov 2001, Ratti wrote: [...] d.h. egal von was (also auch fdisk/mkfs.* oder scandisk) defekte Sektoren gemeldet werden, _wenn_ defekte Sektoren gemeldet werden, dann wurde die Reserve schon aufgebraucht.
Ack
Dann verstehe ich eins nicht: Wenn ein Block kaputt geht, aber noch ausgemappt werden kann - dann müssten die Daten ja futsch sein (Block kaputt), bei Kontrolle aber kein Fehler zu finden sein (ist ja ausgemappt).
Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen (durch mehrfache Leseversuche, die dann "gemittelt" werden und das wahrscheinlichste Ergebnis wird dann verwendet) und auf einen der Reservesektoren kopieren.
Na das scheint mir ja eine recht wilde Technik zu sein...;-) Wenn dieser Sektor z.B. einen Teil einer Textdatei enthält, dann mag man das ja noch verkraften können, aber wenn da eine Binärdatei (Program) liegt, dann kann das eigentlich nur in die Hose gehen mit diesen Schätzwerten.
Die Defekte sind mehr oder weniger schleichend, und je nachdem welche Toleranz in der Firmware eingestellt wurde, wird frueher oder spaeter ein Sektor als "defekt" betrachtet (und in die Reserve verlagert). Von all dem bekommt _keine_ Software ausser der Firmware der HD etwas mit -- auch nicht das BIOS oder ein mkfs/badblocks -- diese bekommen _erst_ etwas mit, wenn die Reserve aufgebraucht ist.
Egal ob schleichend oder nicht, es gibt ja eigentlich nur zwei Möglichkeiten. Entweder er macht das, was Falk hier schreibt:
hier wird auch teilweise einfach beim schreiben mit dem writecache gegengecheckt, ausserdem gibt es prüfsummen über die internen Sektoren deren Grösse genau gar nichts mit dem zu tun hat was die Platte nach aussen hin zeigt.
...was ja auch einleuchtend ist. [...]
Doch -- allerdings nicht "von jetzt auf nachher", sondern schleichend, und somit kann die Firmware die Daten noch in einen Reservesektor kopieren.
vor allem 'merken' es viele Platten erst beim schreiben und das ist das eigentliche Problem. [...]
Wieso? Wenn sie was schreiben wollen und es nicht geht, ziehen sie einen Reserversektor heran und schreiben die Daten aus dem Cache eben dort hin. Ich habe hinterher noch anständige daten. Was passiert aber, wenn es die Platte erst beim lesen merkt? Wenn die Daten schrottig sind, kann ich auch nur noch Schrott wegkopieren. Das ist dann je nach Art der Daten nur mehr oder weniger sinnvoll.
die lange Zahlenliste sind US-Patente. Keine bad blocks. ;-)
Haette mich auch gewundert ;)
auf den guten alten SCSI Platten war das so, allerdings hab ich das noch bei keiner IDE/ATA Platte gesehen und ich hab schon viele gesehen - in letzter Zeit leider zu viele, viel zu oft. :-/
Stimmt, die kenne ich auch noch. Allerdings habe ich das schon seit Jahren nicht mehr gesehen. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
On Tue, 20 Nov 2001, Peter Kuechler wrote:
Am 20-Nov-2001 Falk Sauer schrieb:
On Tue, Nov 20, 2001 at 01:00:15AM +0100, David Haller wrote:
On Mon, 19 Nov 2001, Ratti wrote: [...] Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen (durch mehrfache Leseversuche, die dann "gemittelt" werden und das wahrscheinlichste Ergebnis wird dann verwendet) und auf einen der Reservesektoren kopieren.
Na das scheint mir ja eine recht wilde Technik zu sein...;-) Wenn dieser Sektor z.B. einen Teil einer Textdatei enthält, dann mag man das ja noch verkraften können, aber wenn da eine Binärdatei (Program) liegt, dann kann das eigentlich nur in die Hose gehen mit diesen Schätzwerten.
Naja, schau dir mal die Technik an, mit der heutzutage alle Platten lesen, ich sach nur "GMR" (Giant Magneto Resistance oder so), die von IBM entwickelt wurde (IIRC mit der DHEA oder DTLA Serie eingefuehrt)... Und schon der Vorgaengerprozess war aehnlich. Der Leseprozess ist also auch schon "normal" ein Schaetzwert der aus den Werten mehrerer "Partikel" gemittelt wird... Da gab's nette Artikel in der c't zu... Und wenn dieser Schaetzwert dann eben zu unsicher wird (sagen wir mal, statt > 80% "fuer 1" wird nur noch "zu 75% sicher" erkannt) wird der Sektor dann eben noch mal ausgelesen (ggfs. mehrfach) und die Daten dann in einen Reservesektor geschrieben und der alte als "defekt" eingetragen. Alles IIRC und die Toleranzen sind frei erfunden :)
Die Defekte sind mehr oder weniger schleichend, und [..] Egal ob schleichend oder nicht, es gibt ja eigentlich nur zwei Möglichkeiten. Entweder er macht das, was Falk hier schreibt:
hier wird auch teilweise einfach beim schreiben mit dem writecache gegengecheckt, ausserdem gibt es prüfsummen über die internen Sektoren deren Grösse genau gar nichts mit dem zu tun hat was die Platte nach aussen hin zeigt.
...was ja auch einleuchtend ist.
Oder??
[...]
Doch -- allerdings nicht "von jetzt auf nachher", sondern schleichend, und somit kann die Firmware die Daten noch in einen Reservesektor kopieren.
vor allem 'merken' es viele Platten erst beim schreiben und das ist das eigentliche Problem. [...]
Wieso? Wenn sie was schreiben wollen und es nicht geht, ziehen sie einen Reserversektor heran und schreiben die Daten aus dem Cache eben dort hin. Ich habe hinterher noch anständige daten.
Denke ich auch.
Was passiert aber, wenn es die Platte erst beim lesen merkt? Wenn die Daten schrottig sind, kann ich auch nur noch Schrott wegkopieren. Das ist dann je nach Art der Daten nur mehr oder weniger sinnvoll.
s.o.
die lange Zahlenliste sind US-Patente. Keine bad blocks. ;-)
Haette mich auch gewundert ;)
auf den guten alten SCSI Platten war das so, allerdings hab ich das noch bei keiner IDE/ATA Platte gesehen und ich hab schon viele gesehen - in letzter Zeit leider zu viele, viel zu oft. :-/
Stimmt, die kenne ich auch noch. Allerdings habe ich das schon seit Jahren nicht mehr gesehen.
Naja, wenn man bedenkt, wieviele Sektoren es frueher waren (meine erste, ne 850 MB Platte hatte IIRC um die 1.66 Mill. Sektoren, meine neueste (40 GB) gut 80 Mill... Ne Liste waere heute wohl schnell zu lang... -dnh --
Ansonsten: Ich sage nur ''Diwasserstoffmonoxid''. Ja, ein äußerst schädliches Zeugs, vor allem wenn es in guten Malt gerät. -- A. Schreiber und R. Döblitz in dasr
Hallo, Hier habe ich unklar formuliert und werde folgerichtig bestraft :-)
Das hiesse: Von vornherein defekte Sektoren werden beim Formatieren erkannt und ausgemappt.
From: "David Haller"
Nein.
Erst wenn die Reserve aufgebraucht ist koennen beim formatieren defekte Sektoren erkannt werden -- vorher "luegt" die HD darueber, dass ein Sektor "klammheimlich" schon in den Reservebereich "verlegt" wurde...
Ich habe nicht genau angegeben, _wer_ den Defekt erkennt. Der Rechner erkennt den Defekt nicht beim Formatieren, klar. Bereits das Plattenbios erkennt den Defekt und mappt heimlich aus. Daher meldet der Rechner "OK". Nehmen wir also tatsächlich mal den Fall, mitten drin ist ein Bad Sector. Wir formatieren, HD-Bios erkennt den Fehler, Sektor wird ausgemappt. Wochen später. Daten wurden geschrieben. Der Nachbarsektor geht jetzt auch kaputt. Der Rechner merkt immer noch nix. Das Plattenbios mappt auch diesen Sektor aus, ABER: Was ist mit den Daten? Da war ja was gültiges drauf! Da wird es wohl zwangsläufig darauf hinauslaufen:
Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen [...] und auf einen der Reservesektoren kopieren.
Kann ich mir eigentlich kaum vorstellen, ohne Gänsehaut zu kriegen. In einem verzeifelten, letzmaligen Versuch noch Daten auslesen und ummappen? Huh... Da stellt sich die Frage: Was passiert, wenn ihm das _nicht_ gelingt? Würde er dann den defekten Sektor ausmappen? Das würde bedeuten (Reserve als vorhanden vorausgesetzt), es gehen Daten verloren, der Rechner erfährt aber immer noch nix? Eigentlich müsste er in so einem Fall mit dem ausmappen aufhören, bevor noch mehr in' Eimer geht. Und da denkt man immer, HDs wären sowas simples, quasi Schallplatten mit Programmen drauf. :-) Gruß, Ratti
On Wed, 21 Nov 2001, Ratti wrote:
Ich habe nicht genau angegeben, _wer_ den Defekt erkennt.
Der Rechner erkennt den Defekt nicht beim Formatieren, klar. Bereits das Plattenbios erkennt den Defekt und mappt heimlich aus. Daher meldet der Rechner "OK".
s/Plattenbios/Firmware der HD/ (!)
Nehmen wir also tatsächlich mal den Fall, mitten drin ist ein Bad Sector. Wir formatieren, HD-Bios erkennt den Fehler, Sektor wird ausgemappt.
dito: s/Bios/Firmware/
Wochen später.
Daten wurden geschrieben. Der Nachbarsektor geht jetzt auch kaputt. Der Rechner merkt immer noch nix.
Genau.
Das Plattenbios mappt auch diesen Sektor aus, ABER: Was ist mit den Daten? Da war ja was gültiges drauf!
Da wird es wohl zwangsläufig darauf hinauslaufen:
Nicht ganz. Der Defekt ist in aller Regel nicht sofort komplett, d.h. die Firmware kann i.d.R. die Daten noch auslesen [...] und auf einen der Reservesektoren kopieren.
Kann ich mir eigentlich kaum vorstellen, ohne Gänsehaut zu kriegen. In einem verzeifelten, letzmaligen Versuch noch Daten auslesen und ummappen? Huh...
Ja. Siehe dazu meine anderen Mails, wie die HDs normal gelesen werden, und was dann als "defekt" betrachtet wird. Ok, bei nem Headcrash oder ner anderen mechanischen Zerstoerung der Magnetschicht sind die Daten schlicht und einfach futsch. Aber noch zum Lesen: da versucht die HD eben das zu machen, was in professionellen Labors (Convar, IBAS, u.a.) dann bei schwereren Schaeden gemacht wird, naemlich die noch vorhandene Magnetisierung auszulesen und dann zu "raten", welcher Wert das Bit hatte...
Da stellt sich die Frage: Was passiert, wenn ihm das _nicht_ gelingt? Würde er dann den defekten Sektor ausmappen? Das würde bedeuten (Reserve als vorhanden vorausgesetzt), es gehen Daten verloren,
Ja. Aber wie gesagt, AFAIK sind die "Defekte" als Toleranzschwellen der Magnetisierung/Erkennung eines Wertes definiert...
der Rechner erfährt aber immer noch nix?
AFAIK (da weiss ich aber nix genaues), wuerde so ein ploetzlicher Verlust schon weitergelmeldet (als defekter Sektor)...
Eigentlich müsste er in so einem Fall mit dem ausmappen aufhören, bevor noch mehr in' Eimer geht.
Jein. s.o. Bis auf den Fall des (physikalischen) "Komplettverlustes" ist ein "Defekt" eine Frage der Toleranzschwelle. Und die wird z.B. auch von verschiedenen Herstellern durchaus unterschiedlich definiert. Als Beispiel (ich habe keine Ahnung, wie die Toleranzen wirklich definiert werden) koennte z.B. IBM ab 75% einen Sektor als defekt definieren, ein anderer Hersteller (der wie praktisch alle die gleiche Technologie, GMR, verwendet) aber erst ab 60%... So wuerde also Hersteller A einen Sektor schon ausmappen, wo Hersteller B den Sektor munter als "heil" betrachtet. Diese schleichenden Verluste geschehen AFAIK sowieso und mehr oder weniger staendig, z.B. in oft geschriebenen Sektoren haeufiger als in anderen und die sind mit eingeplant... Und zwar so, dass man bis auf die Ausnahme des physikalischen Defekts eben doch noch die Daten auslesen kann. Wie nah man da an die Grenze herangeht, bei der man noch "sicher" die Daten lesen kann, bzw. ab wann man ein gelesenes Bit nicht mehr als sicher erkannt betrachtet ist halt eine Definitionsfrage... ;) Achso, nochmal zur Sicherheit: alles was ich hier bisher schrieb bezieht sich nicht auf Defekte wie Headcrash oder Abblaettern der Magnetschicht, da kann die HD nix mehr retten, da hilft nur noch ein Ausbauen der Scheiben in einem Reinraum und ein quasi manuelles auslesen der Stellen, die noch lesbar sind bzw. wo die Magnetschicht nicht beschaedigt wurde.
Und da denkt man immer, HDs wären sowas simples, quasi Schallplatten mit Programmen drauf. :-)
Oh, _das_ sind die Dinger schon lange nicht mehr... Ich kann da wirklich nur die Plattenkarussels und die anderen Artikel in der c't als Lektuere empfehlen :) -dnh -- 15: Developer Version Programmpaket mit Dokumentation (Kristian Köhntopp)
participants (8)
-
Alex Klein -
David Haller -
Falk Sauer -
Marc Schiffbauer -
Matthias Popp -
MichaelHoeller＠t-online.de -
Peter Kuechler -
Ratti