Q : MDADM mismatch_cnt> 0. 동의하지 않는 블록을 식별하는 방법은 무엇입니까?

괜찮아. 일상적인 스크럽 후 MDADM RAID5가 mismatch_cnt = 16을보고합니다. 내가 이해하는 것처럼 장치가 읽기 오류를보고하지 않았지만 데이터와 패리티가 일치하지 않는 16 개의 블록이 있음을 의미합니다.

질문 # 1 :이 블록들의 목록을 얻을 수 있습니까?

질문 # 2 : 기본 파일 시스템이 EXT4라고 가정 할 때 # 1이 가능하다고 가정하면 이러한 블록과 관련된 파일을 식별하는 방법이 있습니까?

니어 라인 백업이 있으며 이상적인 세계에서는 라이브 어레이를 백업 데이터와 비교하여 자동으로 손상된 파일을 찾을 수 있습니다. 그러나 실제로는 6TB의 백업 데이터가 엄청나게 비싸고 시간이 많이 걸리는 것을 상기시킵니다. 찾아야 할 곳과 복구 대상을 아는 것이 크게 단순화됩니다.

( 'check'옵션을 사용하여 RAID 스크럽 만 실행한다는 점에 유의해야합니다. '복구'옵션을 사용하여 scrub을 실행하면 MDADM은 데이터 나 패리티가 잘못되었음을 알고 있지만 어느 것을 알지 못하기 때문에 매우 위험 해 보입니다. 따라서 MDADM이 잘못 추측하여 잘못된 데이터를 재구성 할 가능성이 50 % 인 것 같습니다. 따라서 필요한 경우 백업에서 파일을 복원 할 수 있도록 영향을받는 파일을 알고 싶습니다.)

어떤 제안이라도 대단히 감사합니다!

죄송합니다 .'check '는 오류가 발생했을 때 실제로 배열에 다시 씁니다-https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file 참조 /usr/share/doc/mdadm/README.checkarray

'check'는 커널 로그가 다르게 제안 할 수 있지만 읽기 전용 작업입니다 (예 : / proc / mdstat 및 여러 커널 메시지에 "resync"가 언급 됨). FAQ의 질문 21도 참조하십시오.

그러나 읽는 동안 읽기 오류가 발생하면 검사에서 '올바른'데이터를 생성하고이를 기록하려고하는 읽기 오류에 대한 정상적인 응답을 트리거하므로 '확인'이 트리거 될 수 있습니다. 쓰다. 그러나 읽기 오류가 없으면 읽기 전용입니다.

... 찾고있는 데이터를 수집하기에는 이미 너무 늦었을 수 있습니다. 죄송합니다.

장기적으로 RAID5 (및 6, 1)에는 비트 로트에 대한 보호 기능 이 없기 때문에 발생하는 상황 일 수 있습니다. 한 디스크의 데이터가 나빠지면 어떤 데이터가 좋은지 나쁜지를 결정할 방법이 없습니다. btrfs 또는 zfs와 같은 각 디스크를 체크섬하는 파일 시스템으로 마이그레이션하는 것이 좋습니다.

(RAID-5는 실제로 새로운 배포에 사용 해서는 안되며 실제로 원시 디스크의 용량이 각각 2TB 이상인 경우는 안됩니다. http://www.zdnet.com/article/why-raid-5- 2009 년 근무 중지 / )