Unixery & daemon worship 🔥


It's a Unix system! I know this!

Linux: Bad Blocks

Folgende S.M.A.R.T. Attribute sind die wichtigsten Indikatoren für fehlerhafte Sektoren:

  • Reallocated Sectors Count: Count of reallocated sectors. When the hard drive finds a read/write/verification error, it marks that sector as “reallocated” and transfers data to a special reserved area (spare area). This process is also known as remapping, and reallocated sectors are called “remaps”. The raw value normally represents a count of the bad sectors that have been found and remapped.

  • Current Pending Sector Count: Count of “unstable” sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it’s written.

Fehlerhafte Sektoren können nicht mehr gelesen werden, die Daten darin sind also verloren und müssen aus einem Backup wiederhergestellt werden.

BTRFS: Fehlerhafte Dateien identifizieren

Mit BTRFS kann die Datenintegrität überprüft werden, sogenanntes Scrubbing. Bei BTRFS überprüft das Scrubbing nur die Bereiche der Festplatte, auf der sich auch Daten befinden. Um einen “Scrub” zu starten, muss folgender Befehl als root auf einem gemounteten Subvolume ausgeführt werden:

# btrfs scrub start /dev/sda1

Der Status des Scrub kann folgendermaßen abgefragt werden:

# btrfs scrub status /dev/sda1

Hier eine Beispielausgabe eines fehlerhaften Dateisystems:

# btrfs scrub status /dev/sdc1
scrub status for 7e81436a-2de0-47cc-958a-7d03a1429f24
    scrub started at Thu Oct 27 00:23:22 2016 and was aborted after 08:14:00
    total bytes scrubbed: 2.92TiB with 9117 errors
    error details: read=982 csum=8135
    corrected errors: 0, uncorrectable errors: 9117, unverified errors: 0

Außerdem gibt es noch scrub cancel zum Unterbrechen und scrub resume zum Wiederaufnehmen eines Scrub.

In der dmesg Ausgabe finden sich dann Hinweise auf die fehlerhaften Dateien:

# dmesg | grep BTRFS | grep error
...
[15836.136406] BTRFS warning (device sdc1): checksum error at logical 1901610708992 on dev /dev/sdc1, sector 3719342680, root 5391, inode 12360, offset 189681664, length 4096, links 1 (path: photo/abc.jpg)
...
[15996.746912] BTRFS warning (device sdc1): i/o error at logical 1901610266624 on dev /dev/sdc1, sector 3719341816, root 5391, inode 12360, offset 189239296, length 4096, links 1 (path: photo/dfg.jpg)
...

Alternativ (ungetestet):

dmesg | grep BTRFS | grep path | sed -e 's/^.*path: //;s/)$//' | sort | uniq

BTRFS Datenrettung

RAID

Betreibt man BTRFS im raid1 Modus, können die fehlerhaften Dateien automatisch von der intakten Festplatte des Arrays repariert werden, siehe: https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions

Ohne RAID

Hat man kein raid1 und will die Festplatte weiterhin nutzen (da nur ein oder zwei fehlerhafte Sektoren vorhanden sind), muss man die entsprechenden Sektoren mit dd überschreiben und die fehlerhaften Dateien löschen und vom Backup zurücksichern.

Alternativ kann man natürlich auch die Daten auf eine neue Festplatte kopieren und die fehlerhaften Daten vom Backup zurücksichern oder das Backup als neues Live-Medium nutzen.