[Erstmal erledigt] HDD-Probleme: Bad Sector erzeugen?

[TuxPeter]

Hallo Debianfreunde,

bei einer Datensicherung mittels rsync -av /quelle/usw/ /ziel/usw/ ist mir eine Fehlermeldung aufgefallen. (Sicherung von einer Hitachi-300GB SATA, das gesamte HDD ist eine ext4-Part, auf eine USB3-Platte).

Die betroffene Quelldatei ist tatsächlich kaputt. Der Versuch, auf sie zuzugreifen, egal womit, erzeugt folgende Meldung per dmesg:

Code: Alles auswählen

[ 1965.886152] sd 2:0:0:0: [sdb] tag#24 Sense Key : Medium Error [current] 
[ 1965.886161] sd 2:0:0:0: [sdb] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[ 1965.886171] sd 2:0:0:0: [sdb] tag#24 CDB: Read(10) 28 00 12 b6 fe a0 00 00 08 00
[ 1965.886177] blk_update_request: I/O error, dev sdb, sector 313982628

Habe dann hdparm sowie smartctl installiert, was nicht vorhanden war.
nach smartctl --test=long /dev/sdb (1 x wiederholt am nächsten Tag) erhalte ich folgende Werte:

Code: Alles auswählen

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       1
.
.
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       4
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       1
.
.
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Aborted by host               90%     43762         -
# 2  Extended offline    Completed: read failure       50%     43761         313982628
# 3  Extended offline    Completed: read failure       50%     43757         313982628

Wenn ich das alles richtig deute, liegt also ein nicht automatisch korrigierbarer Fehler auf Sektor 313982628 vor.
man hdparm bietet ja folgendes an: --repair-sector sowie --make-bad-sector, warnt aber gleichzeitig wie Tod und Teufel davor. Weiß aber nicht, ob das auch LBA-Angabe oder was anderes ist.

Was meint ihr? Trotzdem probieren? Platte in die Tonne? Laut Smartctl hat sie Power_On_Hours von 43763, aber, wie ich oft genug gelesen habe, muss das ja auch gar nicht stimmen. System ist übrigens Strech, aber das dürfte unerheblich für den Fehler sein. Fehlen noch wesentliche Informationen?

Grüße, TuxPeter

[hikaru]

--repair-sector sollte vergleichsweise harmlos sein. Ich habe damit schon diverse "Pending Sectors" auf sonst unauffälligen HDDs repariert - offenbar ohne zusätzliche Probleme zu verursachen. Meinem Verständnis nach wird der betroffene Sektor dabei einfach überschrieben, sofern technisch möglich natürlich.
Bei HDDs mit 4kB-Sektoren ist dabei zu beachten, dass sowohl der beanstandete als auch die sieben folgenden Sektoren überschrieben werden müssen, da hdparm wohl unabhängig vom tatsächlichen Layout der HDD immer 512B-Sektoren annimmt.

Ich konnte dabei keinen Datenverlust feststellen, hatte aber vorher neben der reinen SMART-Meldung auch keine Hinweise auf Probleme (z.B. beim rsync-Backup). Trotzdem hätte ich das nicht auf einer Platte versucht, von der ich kein Backup habe. Und ein "Raw Read Error" ist im Vergleich zu einem "Pending Sector" durchaus ein ernstzunehmendes Problem.
Ich würde an deiner Stelle versuchen ein rsync-Backup ohne die beschädigte Datei von der Platte zu ziehen (--exclude) und falls das erfolgreich ist versuchen, den Sektor zu reparieren. Mit der genauen Funktionsweise von --make-bad-sector kenne ich mich nicht aus.

[TuxPeter]

Danke für die prompte Antwort!
habe inzwischen eine weitere HDD mit gleicher Größe angesteckt, diesmal von Samsung, und lasse dort einen smartctl-Test machen, das dauert noch. Vielleicht werde ich die Daten dann direkt umschaufeln und dann die jetzt aktive Platte, wie beschrieben, zu reparieren versuchen und als Reserve nehmen.

[rendegast]

Ein einfacher Versuch der Relokation durch die Plattenlogik könnte sein

Code: Alles auswählen

cp  --sparse=never korrekte-kopie  defekte-datei
oder
cat  korrekte-kopie  > defekte-datei

(beachte inode-Nummer 'ls -i defekte-datei')
auf Dateisystemebene.

Dadurch würde die Problematik mit dem lowlevel-Tool umgangen.

Wenn es geklappt hat, sollte 'smartctl -tlong' wieder durchlaufen.
Wobei, der lba, bei dem der smart-Lesetest abgebrochen ist, kann natürlich ein anderer als der der fehlerhaften Datei sein. badblocks treten nicht selten im Rudel auf.
Einen Überblick könnte geben

Code: Alles auswählen

ddrescue --force -r1  /dev/sdX  /dev/zero  /tmp/sdX.log
oder
ddrescue --force -r1  /dev/sdX  /dev/null  /tmp/sdX.log

(mehrmals)
dann kann die Menge und die Lage (sdX.log) festgestellt werden.

[gbotti]

Wobei, der lba, bei dem der smart-Lesetest abgebrochen ist, kann natürlich ein anderer als der der fehlerhaften Datei sein. badblocks treten nicht selten im Rudel auf.

Rudel liest sich echt schön

Einen Überblick könnte geben

Code: Alles auswählen

ddrescue --force -r1  /dev/sdX  /dev/zero  /tmp/sdX.log
oder
ddrescue --force -r1  /dev/sdX  /dev/null  /tmp/sdX.log

(mehrmals)
dann kann die Menge und die Lage (sdX.log) festgestellt werden.

Wäre es hier nicht besser die Platte per ddrescue gleich auf eine andere Platte oder in ein File zu sichern? Das würde eventuellen weitere Datenschäden durch das Stressen umgehen. ddrescue versucht erst alle "guten" Blöcke zu lesen und versucht dann mehrfach die "schlechten" Blöche wiederherzustellen.

[rendegast]

Aus dem Grund habe ich ja auch das '-r1' gesetzt.
Mensch will dem Ding nicht beim Rödeln zuschauen, das kann Stunden dauern und bringt letztendlich auch nichts.
Zudem ist das Ding ja so gedacht, daß mehrere Durchläufe erfolgen.

Ob Du das mit Erstellung eines Rescue-Image verbindest, bleibt Dir überlassen.

[TuxPeter]

Vielen Dank für eure Antworten und Tipps!

Der smartctl-Lauf auf der Ersatzplatte ist inzwischen durch, er zeigt dort keine Fehler an und die Power-On-Time sowie der Power-Cycle-Count sind dort jeweils nur halb so groß, selbst die angezeigte Temperatur ist geringer (33 statt 37 Grad). Ein Umzug - dann mit dem exclude-Param für die defekte Date - erscheint unbedingt angezeigt.

Danach werde ich mal die Sache mit dem ddrescue ausprobieren und mal berichten.

Edit: So, alle Daten sind umgezogen.

Das mit dem rsync -av --exclude=kaputteDatei usw beim Sichern führt trotzdem zur Fehlermeldung, ist aber egal, da alle anderen Files wurden trotzdem korrekt kopiert. Die kaputte Datei hatte ich aber sowieso noch anderswo gesichert.

Edit2: Habe inzwischen diverse, ergebnislose Versuche angestellt, das Laufwerk zu veranlassen, den bad sector selber zu markieren.
schließlich die sowieso kaputte Datei gelöscht und:

Code: Alles auswählen

hdparm --yes-i-know-what-i-am-doing --write-sector 313982628 /dev/sdc
hdparm --yes-i-know-what-i-am-doing --make-bad-sector 313982628 /dev/sdc

hat funktioniert. ddrescue produziert keine Fehler mehr, und smartctl meldet keinen "Raw_Read_Error" mehr, sondern :

Code: Alles auswählen

  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       5
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       5

scheint also alles richtig funktioniert zu haben, trotz oder wegen dieses putzigen "yes-i-know-what-i-am-doing". Könnte man dann ja auch für cp, mv, rm etc einführen.

Vielen Dank für Eure Beiträge,
und schönen Sonntag noch, TuxPeter