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 어레이에서 거의 동일한 문제가 발생했습니다. 불량 섹터는 파티션 중 하나(/dev/sdb2의 섹터 16) 시작 부분에 있습니다. 위의 지침을 따랐습니다. 파일 시스템에서 논리 블록 2가 사용되지 않았는지 확인하고 dd 탐색을 수행하여 올바른 방법으로 건너뛰고 1개의 파일 시스템 블록을 0으로 만든 후:

# 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에 있는 데이터와 비교하면 일치하는 것을 볼 수 있습니다. 따라서 내 경우에는 /dev/sdb2의 논리 블록 2(섹터 16-23)가 파일 시스템에도 없으며 여기에서 읽을 수 있는 RAID 슈퍼 블록에 있습니다. https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- 버전 1.2의 경우 256바이트 + 배열의 장치당 2바이트로 구성되며 모두 4096바이트부터 시작하므로 제 경우에는 배드 섹터가 사용되지 않았습니다. /dev/sdc2(RAID1 배열의 나머지 절반)에 해당하는 섹터는 0이므로 다음과 같이 하는 것이 안전하다고 생각합니다.

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

효율적인!

Answer

RAID1 어레이에서 거의 동일한 문제가 발생했습니다. 불량 섹터는 파티션 중 하나(/dev/sdb2의 섹터 16) 시작 부분에 있습니다. 위의 지침을 따랐습니다. 파일 시스템에서 논리 블록 2가 사용되지 않았는지 확인하고 dd 탐색을 수행하여 올바른 방법으로 건너뛰고 1개의 파일 시스템 블록을 0으로 만든 후:

# 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에 있는 데이터와 비교하면 일치하는 것을 볼 수 있습니다. 따라서 내 경우에는 /dev/sdb2의 논리 블록 2(섹터 16-23)가 파일 시스템에도 없으며 여기에서 읽을 수 있는 RAID 슈퍼 블록에 있습니다. https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- 버전 1.2의 경우 256바이트 + 배열의 장치당 2바이트로 구성되며 모두 4096바이트부터 시작하므로 제 경우에는 배드 섹터가 사용되지 않았습니다. /dev/sdc2(RAID1 배열의 나머지 절반)에 해당하는 섹터는 0이므로 다음과 같이 하는 것이 안전하다고 생각합니다.

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

효율적인!

Question 3

데비안을 실행한다면 /etc/cron.d/mdadm에 작업이 있을 가능성이 높습니다. /usr/share/mdadm/checkarray --cron --all --idle --quiet 매월 첫째주 일요일에 진행 됩니다 . 수정할 수 없는 하드웨어 오류가 발생하면 해당 오류를 수동으로 실행하여 다시 쓰기 속도를 높이세요.

Answer

데비안을 실행한다면 /etc/cron.d/mdadm에 작업이 있을 가능성이 높습니다. /usr/share/mdadm/checkarray --cron --all --idle --quiet 매월 첫째주 일요일에 진행 됩니다 . 수정할 수 없는 하드웨어 오류가 발생하면 해당 오류를 수동으로 실행하여 다시 쓰기 속도를 높이세요.

Question 4

sw-raid1이 있고 구성원 중 한 명에게 직접 데이터를 쓰는 경우 손상된 raid가 즉시 발생합니다. sdaX 또는 sdbX가 mdX의 일부인 경우 여기에 데이터를 쓰지 마십시오. mdX에 쓰면 데이터가 두 드라이브 모두에 복사되고, mdX에서 읽으면 드라이브 중 하나에서 데이터를 읽게 됩니다.

Answer

sw-raid1이 있고 구성원 중 한 명에게 직접 데이터를 쓰는 경우 손상된 raid가 즉시 발생합니다. sdaX 또는 sdbX가 mdX의 일부인 경우 여기에 데이터를 쓰지 마십시오. mdX에 쓰면 데이터가 두 드라이브 모두에 복사되고, mdX에서 읽으면 드라이브 중 하나에서 데이터를 읽게 됩니다.

Linux - GPT를 사용하여 RAID1 어레이의 불량 블록 복구

편집 1:

편집 2

편집 3

답변1

시스템의 모든 RAID 장치에 대한 스크립트

답변2

답변3

답변4

관련 정보