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가 발생합니다. mdX의 일부인 경우 sdaX 또는 sdbX에 데이터를 쓰지 마십시오. mdX에 쓰면 데이터가 두 드라이브 모두에 복사되고, mdX에서 읽으면 드라이브 중 하나에서 데이터가 읽혀집니다.

Answer

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

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

편집 1:

편집 2

편집 3

답변1

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

답변2

답변3

답변4

관련 정보