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.