Linux - GPT を使用した RAID1 アレイ上の不良ブロックの修復

Question 1

これらすべての「セクターを突く」という回答は、率直に言って、非常識です。それらは (おそらく隠れた) ファイルシステムの破損のリスクを伴います。そのディスクに唯一のコピーが保存されていたため、データがすでに消失していたとしたら、それは妥当なことです。しかし、ミラーには完全に正常なコピーが存在します。

mdraid でミラーをスクラブするだけです。不良セクタが検出され、自動的に書き換えられます。

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

適切なデバイスをそこに配置する必要があります (例: mdX ではなく md0)。デフォルトでは配列全体を実行するため、これにはしばらく時間がかかります。十分に新しいカーネルでは、最初にセクター番号を sync_min/sync_max に書き込んで、配列の一部のみに制限することができます。

これは安全な操作です。すべてのmdraidデバイスで実行できます。実際、すべきこれをすべての mdraid デバイスで定期的に実行してください。ディストリビューションには、これを処理するための cronjob が付属している可能性があります。これを有効にするために何かを行う必要があるかもしれません。

システム上のすべての RAID デバイス用のスクリプト

以前、システム上のすべての RAID デバイスを「修復」するスクリプトを書きました。これは、不良セクタを修復できるのは「修復」のみである古いカーネルバージョン用に作成されましたが、現在はチェックを実行するだけで十分です (修復は新しいカーネルでも正常に機能しますが、パリティの再コピー/再構築も行われます。これは、特にフラッシュドライブでは必ずしも望ましい結果ではありません)。

#!/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

checkの代わりにを実行したい場合はrepair、次の (テストされていない) 最初のブロックが機能するはずです。

    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

これらすべての「セクターを突く」という回答は、率直に言って、非常識です。それらは (おそらく隠れた) ファイルシステムの破損のリスクを伴います。そのディスクに唯一のコピーが保存されていたため、データがすでに消失していたとしたら、それは妥当なことです。しかし、ミラーには完全に正常なコピーが存在します。

mdraid でミラーをスクラブするだけです。不良セクタが検出され、自動的に書き換えられます。

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

適切なデバイスをそこに配置する必要があります (例: mdX ではなく md0)。デフォルトでは配列全体を実行するため、これにはしばらく時間がかかります。十分に新しいカーネルでは、最初にセクター番号を sync_min/sync_max に書き込んで、配列の一部のみに制限することができます。

これは安全な操作です。すべてのmdraidデバイスで実行できます。実際、すべきこれをすべての mdraid デバイスで定期的に実行してください。ディストリビューションには、これを処理するための cronjob が付属している可能性があります。これを有効にするために何かを行う必要があるかもしれません。

システム上のすべての RAID デバイス用のスクリプト

以前、システム上のすべての RAID デバイスを「修復」するスクリプトを書きました。これは、不良セクタを修復できるのは「修復」のみである古いカーネルバージョン用に作成されましたが、現在はチェックを実行するだけで十分です (修復は新しいカーネルでも正常に機能しますが、パリティの再コピー/再構築も行われます。これは、特にフラッシュドライブでは必ずしも望ましい結果ではありません)。

#!/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

checkの代わりにを実行したい場合はrepair、次の (テストされていない) 最初のブロックが機能するはずです。

    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

私も RAID1 アレイでほぼ同じ問題に遭遇しました。不良セクタは、パーティションの 1 つの先頭、つまり /dev/sdb2 のセクタ 16 にありました。私は上記の手順に従いました。論理ブロック 2 がファイルシステムによって使用されていないことを確認した後、dd シークとスキップが正しい方向に行われるように注意し、ファイルシステムブロック 1 つをゼロにしました。

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

これは何をしたのでしょうか? 不良セクタは修復されませんでした。これは、/dev/md0 が /dev/sdb2 に直接マップされていないためだとわかりました。RAID データオフセットを考慮する必要があります。これについては後述します。実際に起こったことは、ファイルシステムに小さいながらも壊滅的な影響を与える可能性のある問題でした。/dev/md0 の論理ブロック 2 には有用なファイルシステムメタデータが含まれていて、両方のディスクで問題がなかったのですが、両方/dev/md0 に書き込むことでコピーします。幸いなことに、e2fsck -y /dev/md0 は (驚くほどの出力を吐き出した後) 明らかなデータ損失なしに問題を修正しました。教訓: debugfs icheck が「ブロックが見つかりません」と表示しても、必ずしも対応するセクターが使用されていないことを意味するわけではありません。

データオフセットに戻ります。次のように mdadm を使用してオフセットを見つけます。

# 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)

この場合、データオフセットは 512 バイトの 262144 セクターです。/dev/md0 から dd を実行して、オフセットが 131072K の raw パーティションのデータと比較すると、一致することがわかります。したがって、私の場合、/dev/sdb2 の論理ブロック 2 (セクター 16 ～ 23) はファイルシステム内にはなく、RAID スーパーブロック内にあります。これについては、次のリンクを参照してください。 https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- バージョン 1.2 の場合、アレイ内のデバイスごとに 256 バイト + 2 バイトで構成され、すべて 4096 バイトから始まるため、私のケースでは不良セクターは使用されませんでした。/dev/sdc2 (RAID1 アレイのもう半分) の対応するセクターはゼロなので、次のようにしても安全だと判断しました。

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

出来た！

Answer

私も RAID1 アレイでほぼ同じ問題に遭遇しました。不良セクタは、パーティションの 1 つの先頭、つまり /dev/sdb2 のセクタ 16 にありました。私は上記の手順に従いました。論理ブロック 2 がファイルシステムによって使用されていないことを確認した後、dd シークとスキップが正しい方向に行われるように注意し、ファイルシステムブロック 1 つをゼロにしました。

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

これは何をしたのでしょうか? 不良セクタは修復されませんでした。これは、/dev/md0 が /dev/sdb2 に直接マップされていないためだとわかりました。RAID データオフセットを考慮する必要があります。これについては後述します。実際に起こったことは、ファイルシステムに小さいながらも壊滅的な影響を与える可能性のある問題でした。/dev/md0 の論理ブロック 2 には有用なファイルシステムメタデータが含まれていて、両方のディスクで問題がなかったのですが、両方/dev/md0 に書き込むことでコピーします。幸いなことに、e2fsck -y /dev/md0 は (驚くほどの出力を吐き出した後) 明らかなデータ損失なしに問題を修正しました。教訓: debugfs icheck が「ブロックが見つかりません」と表示しても、必ずしも対応するセクターが使用されていないことを意味するわけではありません。

データオフセットに戻ります。次のように mdadm を使用してオフセットを見つけます。

# 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)

この場合、データオフセットは 512 バイトの 262144 セクターです。/dev/md0 から dd を実行して、オフセットが 131072K の raw パーティションのデータと比較すると、一致することがわかります。したがって、私の場合、/dev/sdb2 の論理ブロック 2 (セクター 16 ～ 23) はファイルシステム内にはなく、RAID スーパーブロック内にあります。これについては、次のリンクを参照してください。 https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- バージョン 1.2 の場合、アレイ内のデバイスごとに 256 バイト + 2 バイトで構成され、すべて 4096 バイトから始まるため、私のケースでは不良セクターは使用されませんでした。/dev/sdc2 (RAID1 アレイのもう半分) の対応するセクターはゼロなので、次のようにしても安全だと判断しました。

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

出来た！

Question 3

Debian を実行している場合は、 /etc/cron.d/mdadm にジョブがある可能性があります。これは/usr/share/mdadm/checkarray --cron --all --idle --quiet 毎月第 1 日曜日に実行されます。修正不可能なハードウェアエラーが発生した場合は、書き換えを迅速に行うために手動で実行してください。

Answer

Debian を実行している場合は、 /etc/cron.d/mdadm にジョブがある可能性があります。これは/usr/share/mdadm/checkarray --cron --all --idle --quiet 毎月第 1 日曜日に実行されます。修正不可能なハードウェアエラーが発生した場合は、書き換えを迅速に行うために手動で実行してください。

Question 4

sw-raid1 があり、メンバーの 1 つに直接データを書き込むと、RAID がすぐに破損します。sdaX または sdbX が mdX の一部である場合は、データを書き込まないでください。mdX に書き込むと、両方のドライブにデータがコピーされますが、mdX から読み取ると、ドライブの 1 つからデータが読み取られます。

Answer

sw-raid1 があり、メンバーの 1 つに直接データを書き込むと、RAID がすぐに破損します。sdaX または sdbX が mdX の一部である場合は、データを書き込まないでください。mdX に書き込むと、両方のドライブにデータがコピーされますが、mdX から読み取ると、ドライブの 1 つからデータが読み取られます。

Linux - GPT を使用した RAID1 アレイ上の不良ブロックの修復

編集1:

編集2

編集3

答え1

システム上のすべての RAID デバイス用のスクリプト

答え2

答え3

答え4

関連情報