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

Re: Disk Read Error sector ...



Gerhard Brauer wrote:

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.

(mit absätzen war der text schon geschrieben, angekommen ist was anderes! komisch, sorry)
Du hast einen Fehler in der Leertaste ;-)

;-)

hmm.. also es handelt sich hier nicht um die boot-platte wo der MBR defekt war sondern um eine zweite platte. Im log steht das auch so:

Analyse Disk /dev/hdb - CHS 30515 255 63 - 239366 MB
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 07
get_geometry_from_list_part_aux head=255 nbr=1
Current partitions:
Invalid NTFS boot
1 P HPFS - NTFS              0   1  1 30514 254 63  490223412
1 P HPFS - NTFS              0   1  1 30514 254 63  490223412
No partition is bootable

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, ...)

Der mount mit diesem (alten) Zustand (s. log) war mit meinen Kenntnissen nicht möglich! In den Syslog oder anderen verdächtigen habe ich diesbezüglicht nichts finden können.
Würde wie gehen?
(p.s.: fsck, das ja ab und an beim boot seinen dienst tut habe ich noch nie in irgend einer log gesehen. Wird das nicht gespeichert? dmsg syslog etc. sagen hier nichts/nie.)

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?
Ja, aber auch ein scann mit anderen tools z.b "ntfsinfo -i 0 -d /dev/hdb1" haben versagt und ähnliche fehler ausgegeben. Aber wie Du schon vermutest: Es waren die Programme die Fehler gemeldet haben. (Werde ich künftig in Reports getrennt sagen.)

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.

Ich habe noch mal das Backup vom Nov. angesehen: Es war doch der gleiche IDE port und damals auch "hdb" (dannach habe ich die neuen Platten (also jene die jetzt spinnt) sogar einbauen lassen). Verdacht auf Kabel, Board, Controler, Bios defekt als mögliche Ursache? (Kommt dem langsam immer näher :-( )

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

Das ging nicht. Fehler ("too many mounted.. or bad block...") war die Meldung. Syslog schwieg. Habe alle logs der letzten tage durch gesehen.

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

Den hab hab ich glatt vergessen :-) (Ich habe mittlerweile fast jedes diag.tool installiert)

Die Windows Tools die ich habe, habe hier diesen Test bestanden.
Der vom Bios her aktivierte Test meldet auch nichts anstössiges.
Ich lese gerade die man zu smartctl verstehe aber mehr "Bahnhof" als brauchbares. Wärend der Scann jetzt läuft bekomme ich aber folgendes direkt angezeigt. (siehe log in anlage). ("smartctl -t long -l selftest /dev/hdb")

Den vollen/ganzen log bekomme ich scheinbar nach Fertigstellung mit dem Aufruf von:
"smartctl -l selftest /dev/hdb" ?
Ich verstehe das dort nicht so ganz :-?

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

"e2fsck" ? auf einer nfts partition? Wie mache ich das?

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

Ich teste noch.
Grundsätzlich Entspannung :-)
Habe bisher die hälfte der Daten gepüft und sie sind ausführ, lesbar und noch nichts Korruptes entdeckt.


Gruß Gerhard

lieben gruß zurück :-)

Florian

########################################################################
~# smartctl -a /dev/hdb
########################################################################
=== START OF INFORMATION SECTION ===
Device Model:     Maxtor 7Y250P0
Serial Number:    Y64LSRAE
Firmware Version: YAR41BW0
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:    Tue May  3 16:45:04 2005 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Disabled

SMART Disabled. Use option -s with argument 'on' to enable it.



########################################################################
~# smartctl -t long -l selftest /dev/hdb
########################################################################
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       40%      1625         6298414
# 2  Extended offline    Completed: read failure       40%      1625         6298414
# 3  Extended offline    Completed: read failure       40%      1625         6298414
# 4  Extended offline    Completed: read failure       40%      1625         6298414

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 107 minutes for test to complete.
Test will complete after Tue May  3 19:01:04 2005

Use smartctl -X to abort test.


Reply to: