# [gelöst] Buffer I/O error on device sdb1

## uhai

Hallo Leute,

schon wieder was kaputt...

Seit ein paar tagen kann ich mich mit meinem user nciht mehr einloggen. Anscheinend ist der zugriff auf home wegen des o.g. Fehlers nicht mehr möglich. Nach dem login als user bleibt der Bildschirm schwarz. Funfact: Thunderbird holt die Emails trotzdem ab....

mit root komme ich ins System und jetzt schreibe ich von einem anderen Gerät die Bildschirmausgabe ab.

DMESG:

```
Buffer I/O error on dev sdb1, logical block 121667584, async page read

ata2: EH complete

ata2.00: exception Emask 0x0 Sact 0x800000 SErr 0x0 action 0x0

ata2.00: irq_state 0x40000008

ata2.00: failed command: READ FPDMA QUEUED

ata2.00: cmd 60/08:b8:00:08:04/00:00:3a:00:00/40 tag 23 ncq dma 4096 in

              res 41/40:00:00:08:04/00:00:3a:00:00/40 Emask 0x409 (media error) <F>

ata2.00: status { DRDY ERR }

ata2.00: error: { UNC }

ata2.00: ATA Identify Device Log not supported

ata2.00: ATA Identify Device Log not supported

ata2.00: configured for UDMA/133

sd 1:0:0:0: [sdb] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=2s

sd 1:0:0:0: [sdb] tag#23 Sense Key : Medium Error [current]

sd 1:0:0:0: [sdb] tag#23 Ad. Sense: Unrecovered read error - auto reallocate failed

sd 1:0:0:0: [sdb] tag#23 CDB: Read(10) 28 00 3a 04 08 00 00 00 08 00

blk_update_request: I/O error, dev sdb, sector 973342720 op 0x0: (READ) flags 0x0 phys_seg 1 prio class 0
```

also habe ich smartmontools installiert. Damit kenne ich mich nicht aus - kann mir da jemand helfen? Was muss ich testen um eine Festplattendefekt auszuschließen bzw. sicher festzustellen? Kann man das evtl. reparieren?

Die Platte ist eine WD Caviar gReen WD-WCAV5N547698.

uhaiLast edited by uhai on Sun Apr 24, 2022 2:30 pm; edited 2 times in total

----------

## mike155

Zuallererst: die Kabel überprüfen bzw. ggf austauschen. Das hat schon manchmal Wunder gewirkt...

Als nächstes:

```
smartctl -a /dev/sdb
```

Bitte das Ergebnis posten. Wenn die Ausgabe länger sein sollte, dann bitte über wgetpaste.

----------

## uhai

Danke Mike155,

Sata-Kabel suche ich mal. aktuell habe ich einen long-Test laufen, der ist fast halb durch. den würde ich abwarten - vermutlich finde ich auch vorher kein Kabel  :Wink: 

Ich melde mich dann mit den Infos....

uhai

----------

## mike155

Es ist gut, ein "smartctl -a /dev/sdb" VOR und NACH dem "Long" Test laufen zu lassen. Dann kann man die Fehler-Counter vergleichen. 

Na, macht nichts. Vielleicht finden wir aussagekräftige Meldungen in den Log-Einträgen der Festplatte.

Man kann "smartctl -a /dev/sdb" auch während des "Long" Tests laufen lassen. Die Fehler-Counter werden ausgegeben und man erhält - je nach Modell - eine Meldung wie "Long Test running. 80% completed, 20% remaining".

Hast Du während des "Long" Tests irgendwelche merkwürdigen Geräusche gehört (Klopfen, kratzende Geräusche, usw.)?

----------

## uhai

So, Kabel gekauft, getauscht, nix erreicht

Die Ausgabe von smartctl -a .,/dev/SDB ist hier:

Http://dpaste.com/8CUT77DJK

uhai

----------

## mike155

```
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Extended offline    Aborted by host               90%        64         -

# 2  Extended offline    Completed: read failure       60%        61         973342720

# 3  Extended offline    Aborted by host               90%        59         -

# 4  Extended offline    Completed: read failure       60%        53         973342720

# 5  Short offline       Completed without error       00%        51         -

```

Das sieht nach einem wirklichen Festplattenfehler aus.

Das Laufwerk scheint noch neu zu sein?

```
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       69
```

Stimmt es, dass die Platte erst 69 Stunden läuft? Oder ist der Wert verkehrt?

Bist Du noch innerhalb der Gewährleistungs-/Garantie-Zeit? Kannst Du die Platte umtauschen?

----------

## uhai

Der Wert  ist sicher verkehrt. Die platte ist "zweitverwendet" in dem Rechner, wie alt die aber ist, kann ich nicht sagen.

Kann man die Daten irgendwie noch retten? Sind alle user-Einstellungen.... die Arbeitsdateien habe ich auf meinem NAS....

uhai

----------

## mike155

Die Antwort ist nicht ganz einfach. Wenn "nur" der Block 973342720 defekt ist, könnte man ihn einfach überschreiben. Dabei würde die Platte den Block an eine andere Stelle verschieben - und man könnte sie weiterverwenden. Allerdings ist häufig mehr defekt als nur ein Block. Wenn es beispielsweise einen Head-Crash gab, ist mindestens ein ganze Spur defekt - und möglicherweise hat auch der Schreib-/Lese-Kopf etwas abbekommen. 

Ebenso hängt das weitere Vorgehen von der Firmware ab. Bei RAID-Platten würde der Controller einfach einen Lese-Fehler zurückmelden. Man könnte aber andere Daten noch problemlos von den Platte lesen. Hier könnte man u.U. mit ddrescue arbeiten. Bei Consumer-Platten versucht die Firmware, einen defekten Block immer und immer wieder zu lesen - so dass man mit der Platte nicht mehr vernünftig arbeiten kann und an andere Daten nicht mehr rankommt. Hier muss man also vermeiden, von defekten Blöcken zu lesen. ddrescue o.ä scheidet also aus.

Vielleicht solltest Du mit der Partitionstabelle anfangen. Ich nehme an, dass auf der Platte mehrere Partitionen sind? Die Daten von manchen Partitionen kannst Du vermutlich ganz normal lesen - und mit diesen solltest Du anfangen. Dann kannst Du Dir die Partition vornehmen, auf der der defekte Block liegt. Ist das die Home-Partition? Kannst Du diese Partition noch zum Lesen mounten? Oder gibt es bereits beim Mounten einen Fehler?

Auf jeden Fall solltest Du aufhören, von der Platte zu booten oder Partitionen davon automatisch einzuhängen. Zugriffe sollten nur noch manuell von Dir erfolgen. Alle Zugriffe nur noch im Read-Only-Modus.

----------

## uhai

Mein Rechner bootet von einer SSD (dev/SDA). Auf sdb1 liegt mein home mit Ausnahme der Arbeitsdaten, die in ein Datenverzeichnis von meinem NAS eingebunden werden. Praktisch startete in System und root an der.Console.funktioniert. Der grafische Login in fluxbox geht !icht, der scheitert am Zugriff auf sdb1. Aber ich kann an der Console sehen, dass meine Arbeitsumgebung (digikam, Thunderbird, firefox) startet und arbeitet. Nur halt.hne sichtbare Fenster.....

Also kommentiere ich sdb1 in fstab mal aus. Dann schau ich mir mal die Partitionen mit parted an. Zuerst wird gesichert, was in den anderen Partitionen auf SDB liegt.

Aktuell.gehört die Platte zu keinem RAID. Aber die WD Green sind dafür gedacht, oder? Ich kann mich nicht erinnern, wo diese Platte ursprünglich verbaut war.....

uhai

<edit> /dev/sdb hat nur eine Partition mit ext4 mitv1 TB </edit>

----------

## mike155

 *Quote:*   

> <edit> /dev/sdb hat nur eine Partition mit ext4 mitv1 TB </edit>

 

Dann würde ich die Partition händisch nach /mnt mounten - und sicherstellen, dass niemand außer mir auf die Partition zugreift. 

Als nächstes würde ich mir die wirklich wichtigen Dateien einzeln raussuchen und mit cp einzeln auf ein anderes Laufwerk kopieren (also nicht: cp -r ...). Mit etwas Glück sollten diese Dateien auf fehlerfreien Blöcken liegen - und das Kopieren sollte funktionieren.

Wenn Du Pech hast, triffst Du beim Kopieren auf defekte Blöcke. Interessant ist, was die Platte dann macht:

Liefert sie einfach nur einen Lesefehler und Du kannst weiterarbeiten?

Will die Platte den defekten Block immer und immer wieder lesen? Gibt die Platte merkwürdige Geräusche von sich?

Gerät die Platte nach einem Lesefehler in einen Zustand, in dem man sie nicht mehr vernünftig kann?

Wenn Du die wirklich wichtigen Dateien sichern konntest, kannst Du im nächsten Schritt anfangen, mit "cp -r" größere Bereiche zu kopieren.

----------

## uhai

ok, jetzt habe ich meine RAM-Module getestet und 2 defekte entfernt. Dann mount -r /dev/sdb1 gemacht und folgende Ausgabe bekommen:

```
ata2.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x0

ata2.00: irq_stat 0x40000008

ata2.00: failed command: READ FPDMA QUEUED

ata2.00: cmd 60/08:10:00:08:04/00:003a:00p:00/40 tag 2 ncq dma 4096 in

             res 41/40:00:00:08:04/00:00:3a:00:00/40 Emask 0x409 (media error) <F>

ata2.00: status: {DRDY ERR}

ata2.00: error: { UNC }

ata2.00: ATA Identify Device Log not supported

ata2.00: ATA Identify Device Log not supported

ata2.00: configured for UDMA/133

sd 1:0:0:0 [sdb] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=2s

sd 1:0:0:0 [sdb] tag#2 Sense Key : Medium Error [current]

sd 1:0:0:0 [sdb] tag#2 Add: Sense: Unrecovered read error - auto reallocate failed

sd 1:0:0:0 [sdb] tag#2 CDB: Read(10) 28 00 3a 04 00 00 00 08 00

blk_update_request: I/O error, dev sdb, sector 973342720 op 0x0:(RED) flags 0x0 phys_seg 1 prio cass 0

ata2: EH complete

JBD2: IO error reading journal superblock

EXT4-fs (sdb1) error loading journal

mount /home/uhai/Daten: Der Superblock von /dev/sdb1 konnte nicht gelesen werden.
```

Gibt es den Superblock bei ext4 nicht mehrfach auf der Platte? Kann ich den defekten damit dann nicht überschreiben? Oder ist das dieses " auto reallocate failed"?

uhai

----------

## mike155

Es sieht so aus, als ob der ext4 Treiber beim Mounten das Journal abspielen will. Offenbar liegt ein Teil des Journals auf Block 973342720. Und der ist defekt, wie wir ja bereits von Deinen "Long"-Tests wissen. Also gibt es einen Lese-Fehler.

Mit Deinem Befehl

```
mount -r /dev/sdb1 /mnt
```

versuchst Du, das Laufwerk im Read-Only Modus zu starten. Das ist richtig! Nichtsdestotrotz wird das Journal abgespielt. 

"man ext4" schreibt zu der Option "-r":

 *Quote:*   

> Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block device itself to read-only mode, see the blockdev( 8 ) command.
> 
> 

 

Eigentlich steht hier, was zu tun ist. Du musst das Laufwerk im Read-Only Modus mounten - aber zusätzlich verhindern, dass das Journal abgespielt wird. 

Mounte das Laufwerk folgendermaßen:

```
mount -o ro,noload /dev/sdb1 /mnt
```

Damit wirst Du Änderungen verlieren, die nur im Journal, aber noch nicht im Datenbereich stehen. In den meisten Fällen ist das jedoch nicht viel - und ältere Dateien sollten davon nicht betroffen sein. Möglicherweise sind ein paar der Dateien, die Du zuletzt geschrieben hast, verschwunden oder kaputt. Möglicherweise ist aber auch alles in Ordnung.

----------

## uhai

So geht es:

Mount -o ro,noload -> keine Fehlermeldung mehr!

505/GB belegt.... Ich habe hier nur noch eine 500GB SSD in Reserve..... muss ich noch ein Laufwerk besorgen.Ist der Fehler jetzt eher eine Hardware-Alterserscheinung oder kann man das softwaremäßig reparieren?

Anders gefragt: Laufwerk ersetzen oder fsck & Kollegen?

uhai

----------

## mike155

Ich persönlich würde das Laufwerk ersetzen.

Du kannst folgendes machen:

Kopiere alle Daten von der Platte.

Lies die Smart-Parameter aus und speichere sie in eine Datei:

```
smartctl -a /dev/sdb >/root/smartctl-1.txt
```

Überschreibe die Platte vollständig:

```
dd if=/dev/zero of=/dev/sdb bs=100M
```

ACHTUNG: die Platte wird dabei gelöscht. Stelle sicher, dass Du alle Daten runterkopiert hast und dass sich hinter sdb auch wirklich Platte befindet, die Du überschreiben willst. Wenn Du die falsch Platte erwischt, sind dort alle Daten weg.   :Shocked: 

Lies die Smart-Parameter aus

```
smartctl -a /dev/sdb >/root/smartctl-2.txt
```

Die Platte müsste die ihr bekannten defekten Blöcke beim Überschreiben verschoben haben. 

Deshalb sollte der Parameter "Reallocated_Sector_Ct" jetzt höher sein. Ist er das? Vergleiche /root/smartctl-1.txt und /root/smartctl-2.txt.

Lies die gesamte Platte aus und schaue, ob es Lese-Fehler gibt:

```
dd if=/dev/sdb of=/dev/null bs=100M
```

Wenn es keine Fehler gibt und 

sich auch die Fehlerzähler 

```
smartctl -a /dev/sdb >/root/smartctl-3.txt
```

beim Auslesen der Platte nicht weiter erhöht haben (vergleiche /root/smartctl-2.txt und /root/smartctl-3.txt), kannst Du die Platte weiter benutzen. 

Ich wäre aber trotzdem vorsichtig und würde nichts Wichtiges darauf speichern. Die Tatsache, dass ausgerechnet ein Sektor des Journals defekt ist, lässt nichts Gutes erahnen... 

Falls Du dich entschließt, die Festplatte zu entsorgen, könntest Du sie vorsichtig öffnen (wenn Du Lust hast) und schräg auf die Platten schauen, so dass sich das Licht spiegelt. Möglicherweise siehst Du dann auf einer der Platten eine Rille. Dann wüsstest Du, dass Du einen Head Crash hattest.

Ich habe das vor vielen Jahren einmal gesehen  - und es ist mir in Erinnerung geblieben. Wenn man das gesehen hat, ist einem auch klar, dass da nicht nur eine Spur der Platte weggefräst ist - sondern dass auch der Schreib-Lese-Kopf etwas abbekommen haben muss - weshalb man die Platte besser nicht mehr benutzten sollte.

Es kann aber auch sein, dass Du keinen Head Crash hattest, sondern dass "nur" irgendwo auf der Platte ein paar Stellen nicht ordentlich funktionieren. Das kann vorkommen und wäre nicht weiter schlimm. Die Platte kann solche Blöcke verschieben und man kann weiterarbeiten. Es ist aber unwahrscheinlich, dass sich diese defekten Stellen genau an der Stelle befinden, wo das Journal liegt. Das deutet doch eher auf ein größeres Problem oder sogar auf einen Head Crash hin.

Last edited by mike155 on Tue Apr 12, 2022 8:08 pm; edited 1 time in total

----------

## uhai

Danke Dir Mike155,

morgen besorgen ich die fehlenden 16 GB RAM und eine passende Festplatte. Die eingebaute WD werde ich testen und ggfs. ersetzen.

Danke für Deine hilfreiche Anleitung. Ich melde dann den Erfolg, Kann aber ein bisschen dauern.....

uhai

----------

## mike155

Dass auch noch das RAM defekt ist - und auch gleich noch 2 Riegel - finde ich merkwürdig. Gibt es einen offensichtlichen Grund dafür?

Im Nachbar-Thread wurde geschrieben, dass es fehlerhafte Versionen von Memtest gibt, die auch Defekte bei fehlerfreiem RAM finden: https://forums.gentoo.org/viewtopic-p-8699372.html#8699372

Was ist mit Deinem Netzteil? Ist das in Ordnung?

----------

## uhai

Ok, jetzt hab ich es im Griff....

Ram getauscht, Festplatte kopiert, getauscht und die defekte abgeklemmt... zu mehr reicht die zeit aktuell nicht.

Das RAM habe ich entdeckt, weil qtwebenginge sich nicht mehr emergen ließ.... Passt jetzt, also nehme ich an, das war echt defekt.

Netzteil läuft, wie kann ich das weiter testen?

Jedenfalls vielen Dank Dir mike155, ohne dich hätte ich das vermutlich gar nicht in den Griff bekommen.

uhai

----------

## arfe

 *uhai wrote:*   

> Das RAM habe ich entdeckt, weil qtwebenginge sich nicht mehr emergen ließ.... Passt jetzt, also nehme ich an, das war echt defekt.

 

Es war definitiv defekt.

----------

## mike155

 *uhai wrote:*   

> Das RAM habe ich entdeckt, weil qtwebenginge sich nicht mehr emergen ließ.... Passt jetzt, also nehme ich an, das war echt defekt.

 

 *arfe wrote:*   

> Es war definitiv defekt.

 

Ah! Das defekte RAM bezog sich auf den Thread vom Februar. Da war etwas... Ich muss zugeben, dass ich diesen Thread schon fast vergessen hatte.  :Smile: 

Ihr habt aber Recht: wir hatten damals festgestellt, dass das RAM defekt ist.

 *Quote:*   

> Netzteil läuft, wie kann ich das weiter testen? 

 

Bitte ignoriere meine Frage. Sie würde nur Sinn ergeben, wenn mehrere Teile im Computer gleichzeitig "kaputt gehen". Das wäre sehr ungewöhnlich. Manchmal ist es dann das Netzteil, das defekt ist - und das (kurzzeitig) Über- oder Unterspannungen abgibt. Das kann dazu führen, dass andere Komponenten sich so verhalten, als ob sie defekt wären. Dein RAM war aber wohl wirklich defekt. Dein Netzteil ist sehr wahrscheinlich in Ordnung. Ich sehe jedenfalls keinen Grund, da weiter zu suchen!

----------

