그래서 저는 현재 홈 서버에 연결된 mdadm RAID5 어레이를 구축하고 있습니다. 하드웨어는 Mediasonic Probox 4베이 케이스와 함께 제공되는 Odroid N2 SBC입니다. 어레이는 현재 재구축 중이며 며칠 동안 진행되었지만 진행 상황은 꾸준합니다. 저는 이전 4.9.180 커널과 함께 armbianstretch를 사용하고 있습니다.
어젯밤에 저는 시스템(드라이브 제외) 작업을 하면서 다른 USB 드라이브에 있는 파일에 대해 체크섬을 실행하고 있었습니다. 현재 N2의 USB 드라이버에는 높은 I/O 활동으로 인해 악화되는 해결되지 않은 버그가 있습니다. N2는 이후 어젯밤 11시 40분경에 사망했습니다.
N2는 거의 즉시 돌아왔고 아침까지 눈치채지 못했습니다. 그러나 mdadm 배열 재구축은 75%에서 일시 중지됩니다. 재구축을 재개했고 잘 진행되었지만 새 어레이에 지속적인 손상을 입히지 않았는지 확인하고 싶었습니다.
패리티 데이터에 오류가 없는지 확인하는 데 사용할 수 있는 mdadm 유틸리티가 있습니까? 어레이에 파일 시스템이 없으므로 이 경우 fsck를 사용할 수 없을 것 같습니다.
답변1
(현재 재구축이 완료된 후) 검사를 실행할 수 있습니다:
mdadm --wait /dev/mdX # wait for rebuild to finish
mdadm --action=check /dev/mdX
# or if mdadm is too old:
echo check > /sys/block/mdX/md/sync_action
그런 다음 시청하세요 mismatch_cnt
.
watch cat /sys/block/mdX/md/mismatch_cnt
0으로 유지되는 한 패리티는 괜찮습니다.
을 살펴보실 수도 있습니다 man md
.SCRUBBING AND MISMATCHES
A count of mismatches is recorded in the sysfs file md/mismatch_cnt.
This is set to zero when a scrub starts and is incremented whenever a
sector is found that is a mismatch. md normally works in units much
larger than a single sector and when it finds a mismatch, it does not
determine exactly how many actual sectors were affected but simply adds
the number of sectors in the IO unit that was used. So a value of 128
could simply mean that a single 64KB check found an error (128 x
512bytes = 64KB).
이 프로세스는 재구축 자체만큼 오랜 시간이 걸립니다. 기본적으로 재구축과 동일한 작업을 수행하기 때문입니다. 진행 상황을 참조하세요 /proc/mdstat
.
75% 정도만 확인하려는 경우 특정 영역만 테스트하는 것도 가능하지만 명령 옵션이 없기 때문에 더 복잡합니다 mdadm
. 를 설정하여 범위를 결정할 수 있습니다 md/sync_min
( 기본 범위는 전체 장치에 적용됩니다).md/sync_max
0-max
고정 패리티를 원할 경우 순수 정보 제공 대신 고정 패리티를 check
사용하십시오 . repair
하지만 데이터가 올바른지, 패리티가 올바르지 않은지 확인해야 합니다. 그렇지 않고 잘못된 데이터(데이터 또는 패리티)가 포함된 단일 디스크를 식별할 수 있는 경우 해당 디스크를 삭제하고 새 디스크로 추가한 후 다시 재구축해야 합니다.
불행하게도 불일치 처리를 위한 올바른 조치 과정을 결정하는 것은 매우 복잡할 수 있습니다...