Linux - Reparieren fehlerhafter Blöcke in einem RAID1-Array mit GPT

Question 1

Alle diese „Sektor anstupsen“-Antworten sind, offen gesagt, verrückt. Sie riskieren eine (möglicherweise versteckte) Beschädigung des Dateisystems. Wenn die Daten bereits weg wären, weil auf dieser Festplatte die einzige Kopie gespeichert ist, wäre das vernünftig. Aber auf dem Spiegel befindet sich eine vollkommen gute Kopie.

Sie müssen nur mdraid den Spiegel bereinigen lassen. Es erkennt den fehlerhaften Sektor und schreibt ihn automatisch neu.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Sie müssen dort das richtige Gerät eingeben (z. B. md0 statt mdX). Dies dauert eine Weile, da standardmäßig das gesamte Array ausgeführt wird. Auf einem ausreichend neuen Kernel können Sie zuerst Sektornummern in sync_min/sync_max schreiben, um es auf nur einen Teil des Arrays zu beschränken.

Dies ist ein sicherer Vorgang. Sie können ihn auf allen Ihren mdraid-Geräten durchführen. TatsächlichsollenFühren Sie dies regelmäßig auf allen Ihren mdraid-Geräten durch. Ihre Distribution wird wahrscheinlich mit einem Cronjob ausgeliefert, der dies handhabt. Vielleicht müssen Sie etwas tun, um ihn zu aktivieren?

Skript für alle RAID-Geräte im System

Vor einiger Zeit habe ich dieses Skript geschrieben, um alle RAID-Geräte im System zu „reparieren“. Es wurde für ältere Kernel-Versionen geschrieben, bei denen nur „Reparieren“ den fehlerhaften Sektor reparieren konnte; jetzt reicht es aus, einfach „check“ auszuführen (das Reparieren funktioniert bei neueren Kerneln immer noch einwandfrei, aber es kopiert/rekonstruiert auch die Parität neu, was nicht immer erwünscht ist, insbesondere bei Flash-Laufwerken).

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

checkWenn Sie anstelle von Folgendes tun möchten repair, sollte dieser (ungetestete) erste Block funktionieren:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Answer

Alle diese „Sektor anstupsen“-Antworten sind, offen gesagt, verrückt. Sie riskieren eine (möglicherweise versteckte) Beschädigung des Dateisystems. Wenn die Daten bereits weg wären, weil auf dieser Festplatte die einzige Kopie gespeichert ist, wäre das vernünftig. Aber auf dem Spiegel befindet sich eine vollkommen gute Kopie.

Sie müssen nur mdraid den Spiegel bereinigen lassen. Es erkennt den fehlerhaften Sektor und schreibt ihn automatisch neu.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Sie müssen dort das richtige Gerät eingeben (z. B. md0 statt mdX). Dies dauert eine Weile, da standardmäßig das gesamte Array ausgeführt wird. Auf einem ausreichend neuen Kernel können Sie zuerst Sektornummern in sync_min/sync_max schreiben, um es auf nur einen Teil des Arrays zu beschränken.

Dies ist ein sicherer Vorgang. Sie können ihn auf allen Ihren mdraid-Geräten durchführen. TatsächlichsollenFühren Sie dies regelmäßig auf allen Ihren mdraid-Geräten durch. Ihre Distribution wird wahrscheinlich mit einem Cronjob ausgeliefert, der dies handhabt. Vielleicht müssen Sie etwas tun, um ihn zu aktivieren?

Skript für alle RAID-Geräte im System

Vor einiger Zeit habe ich dieses Skript geschrieben, um alle RAID-Geräte im System zu „reparieren“. Es wurde für ältere Kernel-Versionen geschrieben, bei denen nur „Reparieren“ den fehlerhaften Sektor reparieren konnte; jetzt reicht es aus, einfach „check“ auszuführen (das Reparieren funktioniert bei neueren Kerneln immer noch einwandfrei, aber es kopiert/rekonstruiert auch die Parität neu, was nicht immer erwünscht ist, insbesondere bei Flash-Laufwerken).

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

checkWenn Sie anstelle von Folgendes tun möchten repair, sollte dieser (ungetestete) erste Block funktionieren:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Question 2

Ich hatte gerade so ziemlich das gleiche Problem mit einem RAID1-Array. Der fehlerhafte Sektor befand sich direkt am Anfang einer der Partitionen – Sektor 16 von /dev/sdb2. Ich folgte den obigen Anweisungen: Nachdem ich überprüft hatte, dass der logische Block 2 nicht vom Dateisystem verwendet wurde, und darauf geachtet hatte, dass DD Seek und Skip in der richtigen Reihenfolge ausgeführt wurden, setzte ich einen Dateisystemblock auf Null:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

Was hat das bewirkt? Der fehlerhafte Sektor wurde nicht repariert. Das liegt, wie ich jetzt weiß, daran, dass /dev/md0 nicht direkt auf /dev/sdb2 abgebildet wird, man muss den RAID-DATENOFFSET berücksichtigen! Mehr dazu weiter unten. Was es bewirkt hat, war ein kleiner, aber potenziell verheerender Haufen Mist auf meinem Dateisystem. Es stellte sich heraus, dass der logische Block 2 von /dev/md0 nützliche Dateisystemmetadaten enthielt und auf beiden Festplatten in Ordnung war, bis ichbeideKopien durch Schreiben in /dev/md0. Glücklicherweise hat e2fsck -y /dev/md0 das Problem behoben (nachdem es eine alarmierende Menge an Ausgabe ausgegeben hatte), ohne dass es zu sichtbarem Datenverlust kam. Lektion gelernt: Wenn debugfs icheck „Block nicht gefunden“ anzeigt, bedeutet das nicht unbedingt, dass die entsprechenden Sektoren nicht verwendet werden.

Zurück zum Datenoffset: Verwenden Sie mdadm, um den Offset wie folgt zu finden:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

In diesem Fall beträgt der Datenoffset 262144 Sektoren mit je 512 Bytes. Wenn Sie von /dev/md0 aus dd ausführen und es mit Daten aus der Rohpartition mit einem Offset von 131072K vergleichen, werden Sie feststellen, dass sie übereinstimmen. In meinem Fall befindet sich der logische Block 2 (Sektoren 16-23) von /dev/sdb2 also nicht einmal im Dateisystem; er befindet sich im RAID-Superblock, über den Sie hier mehr erfahren können: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- für Version 1.2 besteht es aus 256 Bytes + 2 Bytes pro Gerät im Array, alles beginnend bei 4096 Bytes, also wurde in meinem Fall der fehlerhafte Sektor nicht verwendet. Die entsprechenden Sektoren von /dev/sdc2 (die andere Hälfte des RAID1-Arrays) sind Null, also dachte ich, es wäre sicher, dies zu tun:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Es funktionierte!

Answer

Ich hatte gerade so ziemlich das gleiche Problem mit einem RAID1-Array. Der fehlerhafte Sektor befand sich direkt am Anfang einer der Partitionen – Sektor 16 von /dev/sdb2. Ich folgte den obigen Anweisungen: Nachdem ich überprüft hatte, dass der logische Block 2 nicht vom Dateisystem verwendet wurde, und darauf geachtet hatte, dass DD Seek und Skip in der richtigen Reihenfolge ausgeführt wurden, setzte ich einen Dateisystemblock auf Null:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

Was hat das bewirkt? Der fehlerhafte Sektor wurde nicht repariert. Das liegt, wie ich jetzt weiß, daran, dass /dev/md0 nicht direkt auf /dev/sdb2 abgebildet wird, man muss den RAID-DATENOFFSET berücksichtigen! Mehr dazu weiter unten. Was es bewirkt hat, war ein kleiner, aber potenziell verheerender Haufen Mist auf meinem Dateisystem. Es stellte sich heraus, dass der logische Block 2 von /dev/md0 nützliche Dateisystemmetadaten enthielt und auf beiden Festplatten in Ordnung war, bis ichbeideKopien durch Schreiben in /dev/md0. Glücklicherweise hat e2fsck -y /dev/md0 das Problem behoben (nachdem es eine alarmierende Menge an Ausgabe ausgegeben hatte), ohne dass es zu sichtbarem Datenverlust kam. Lektion gelernt: Wenn debugfs icheck „Block nicht gefunden“ anzeigt, bedeutet das nicht unbedingt, dass die entsprechenden Sektoren nicht verwendet werden.

Zurück zum Datenoffset: Verwenden Sie mdadm, um den Offset wie folgt zu finden:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

In diesem Fall beträgt der Datenoffset 262144 Sektoren mit je 512 Bytes. Wenn Sie von /dev/md0 aus dd ausführen und es mit Daten aus der Rohpartition mit einem Offset von 131072K vergleichen, werden Sie feststellen, dass sie übereinstimmen. In meinem Fall befindet sich der logische Block 2 (Sektoren 16-23) von /dev/sdb2 also nicht einmal im Dateisystem; er befindet sich im RAID-Superblock, über den Sie hier mehr erfahren können: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- für Version 1.2 besteht es aus 256 Bytes + 2 Bytes pro Gerät im Array, alles beginnend bei 4096 Bytes, also wurde in meinem Fall der fehlerhafte Sektor nicht verwendet. Die entsprechenden Sektoren von /dev/sdc2 (die andere Hälfte des RAID1-Arrays) sind Null, also dachte ich, es wäre sicher, dies zu tun:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Es funktionierte!

Question 3

Wenn Sie Debian verwenden, haben Sie höchstwahrscheinlich einen Job in /etc/cron.d/mdadm . Dieser wird /usr/share/mdadm/checkarray --cron --all --idle --quiet jeden ersten Sonntag im Monat ausgeführt. Führen Sie ihn manuell aus, wenn Sie nicht korrigierbare Hardwarefehler erhalten, um das Neuschreiben zu beschleunigen.

Answer

Wenn Sie Debian verwenden, haben Sie höchstwahrscheinlich einen Job in /etc/cron.d/mdadm . Dieser wird /usr/share/mdadm/checkarray --cron --all --idle --quiet jeden ersten Sonntag im Monat ausgeführt. Führen Sie ihn manuell aus, wenn Sie nicht korrigierbare Hardwarefehler erhalten, um das Neuschreiben zu beschleunigen.

Question 4

Wenn Sie ein sw-raid1 haben und Daten direkt auf eines der Mitglieder schreiben, wird Ihr Raid sofort beschädigt. Schreiben Sie KEINE Daten auf ein sdaX oder sdbX, wenn diese Teil eines mdX sind. Wenn Sie auf mdX schreiben, werden die Daten auf beide Laufwerke kopiert, wenn Sie von mdX lesen, werden die Daten von einem der Laufwerke gelesen.

Answer

Wenn Sie ein sw-raid1 haben und Daten direkt auf eines der Mitglieder schreiben, wird Ihr Raid sofort beschädigt. Schreiben Sie KEINE Daten auf ein sdaX oder sdbX, wenn diese Teil eines mdX sind. Wenn Sie auf mdX schreiben, werden die Daten auf beide Laufwerke kopiert, wenn Sie von mdX lesen, werden die Daten von einem der Laufwerke gelesen.

Linux - Reparieren fehlerhafter Blöcke in einem RAID1-Array mit GPT

BEARBEITEN 1:

BEARBEITEN 2

BEARBEITEN 3

Antwort1

Skript für alle RAID-Geräte im System

Antwort2

Antwort3

Antwort4

verwandte Informationen