[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Disk Read Error sector ...



Gruesse!
* Florian (flobee) <flobee@gmx.net> schrieb am [02.05.05 17:25]:

> >"Read error ohne Ende" heißt, das du für mehrere unterschiedliche
> >Sektoren Lesefehler bekommst? Wenn ja, geht IMHO die Platte hinüber.
> In der Anlage habe ich den letzten Durchlauf von "testdisk" als Log.
> testdisk war trotz der fehler die ich dort nicht verstehe in der lage
> den fehler anzuzeigen.( die anzahl der fehler varierte. in der text
> datei sieht das wesentlich weniger aus als an der konsole :-o bei
> einem weiteren test (analyse) kommen diese fehler nicht mehr.  fragen:
> - testdisk bot an, den bootsector mit einer gesicherten kopie zu
> ersetzen. gibt es auf jeder partition/disk soetwas oder ist das ein
> feature von testdisk ? dies ist mir neu.  habe ich aber mal gemacht
> und schwupdiwup dat flupte wieder.  

Konntedenndieplattenichtmehrbooten? Davonhastdunichtsgeschrieben. Wennsienichtmehrbootenkonntewardieursachesicherlicheindefekterbootsektor. Aberdaseigentlichedateisystemsolltedavonnichtbetroffensein.

;-)

Will sagen: auch ohne Bootsektor kann ich jede beliebige Partition mit
intaktem Filesystem unter Linux mounten. Wenn das *nicht* geht ist die
Ursache meistens fehlerhafte Partitions-Tabelle, logische Fehler des
jeweiligen Filesystems-Typ oder halt Hardware-seitige Fehler (Platte,
Controller, Kabel, RAM, Board, ...)

Wenn also nach dem testdisk Lauf (ich kenne dieses Tool nicht) alles
wieder funktioniert würde mich das doch wundern. Meine bisherige
Erfahrungen mit "read errors" waren bisher immer ein bestehender bzw.
sich ankündigender Defekt der Platte (oder halt Kabel,RAM,etc).

Aber nachdem ich jetzt das testdisk-Log gesehen habe vermute ich, daß
deine Angaben zu read errors nur von Ausgaben dieses Programms
herrühren? Ich dachte, die kämen vom Kernel und aus der /var/log/syslog.
Wenn sich bei testdisk die read error Ausgaben nur auf einen
fehlerhaften bzw. nicht vorhandenen Bootsektor beziehen dann erhält das
Ganze einen vollkommen neuen Sinn.

Dann hätte aber trotzdem ein:
mount -t ntfs /dev/hdb1 /wohinauchimmer
funktionieren müssen.

> die frage nur: wie lange? hat es
> aufgrund irgendeiner tatsache möglicher weise "nur" den bootsector
> zerlegt oder besteht weiterer gefahr daten zu verlieren/ einen neuen
> crsh zu erleben? (nach erfolgreichem backup gehe ich dem aber mal auf
> den grund, habe 3 ideen den fehler ggf noch mal zu re-produzieren
> mount,mount e2fs f. win, echtes hardware problem (weil gleicher
> rechner wie im nov.) aber anderer ide controller)

Um zu sehen, ob du der Platte noch trauen kannst (an deine Daten kommst
du ja scheinbar wieder ran) würde ich alles auf die zweite Platte
packen/sichern. Wenn die Problem-Platte dann frei ist zum Testen würde
ich:

a) mit den smartmontools diverse SMART-Tests über die Platte jagen

b) die Platte mit badblocks (aus dem Packet e2fsprogs) einem
destruktivem Badblock-Scan unterziehen.

Wenn beides keine ersichtlichen Fehler (v.a. Read/Write Errors) erzeugt,
dann ist die Platte wohl doch in Ordnung.

> >Gruß Gerhard
> 
> lieben gruß zurück Florian

Gruß Gerhard

-- 
DSSP - Deutschland sucht den Super Papst
Casting mit Fliege



Reply to: