mdadm을 사용한 비트 썩음 감지 및 수정

내 홈 리눅스 박스 NAS에서 모든 HDD를 재구성하려고하며 데이터 보호 및 어레이 재구성을위한 유연성을 위해 mdadm raid를 사용하고 싶습니다. 그러나 이것을 위해 mdadm을 사용하기 전에 비트 rot 처리 방법을 알고 싶습니다 . 특히 복구 할 수없는 읽기 오류 메시지가 발생하지 않는 종류의 비트 썩음이 HDD에서 전송됩니다.

NAS의 8 개 디스크에 최소 21TB의 HDD를 사용하고 HDD 의 고장 가능성 에 대한 다양한 인용문을 사용 한다고 가정 할 때 단일 디스크 장애로 복구하는 동안 합리적으로 발생할 수 있다고 생각합니다 나머지 디스크에는 어떤 형태의 비트 썩음이 있습니다. 드라이브 중 하나에서 복구 할 수없는 읽기 오류 인 경우 드라이브가 실제로 오류로보고하면 raid6 (괜찮습니까)에 문제가 없다고 생각합니다. 그러나 디스크에서 읽은 데이터가 좋지 않지만 디스크에 의해 그렇게보고되지 않으면 raid6을 사용하여 어떻게 자동으로 수정할 수 있는지 알 수 없습니다. 이것이 우리가 염려해야 할 것입니까? 문서를 감안할 때 그것은 2010되고 RAID5는 여전히 작동집에서나 직장에서 성공한 경험은 번거로운 단어 나 마케팅이 생각하는 것만 큼 운명과 우울한 것이 아니라 HDD가 고장 나서 백업에서 복원해야하는 것을 싫어합니다.

사용 패턴이 최대 몇 번이고 때때로 읽는다는 점을 감안할 때 데이터 스크러빙 을 수행해야합니다 . archlinux wiki 에서 배열을 스크러빙 하는 데이터에 대한 mdadm 명령을 볼 수 있습니다 .

echo check > /sys/block/md0/md/sync_action

그런 다음 진행 상황을 모니터링

cat /proc/mdstat

이것은 모든 디스크의 모든 섹터를 읽고 데이터가 패리티와 일치하고 그 반대인지 확인하는 것으로 보입니다. 문서에서 "확인"작업이 자동으로 수정되지 않고 감지 만 할 수 있으며 사용자가 수정해야 할 중요한 상황이 있다고 말하는 데는 강조가 중요합니다.

비트 썩음으로부터 보호를 극대화하기 위해 어떤 mdadm RAID 레벨을 선택하고 어떤 유지 보수 및 기타 보호 단계를 수행해야합니까? 그리고 이것이 나를 어떻게 보호하지 못할까요?

편집 : RAID vs ZFS 또는 다른 기술 QA를 시작하지 않습니다. mdadm raid에 대해 구체적으로 알고 싶습니다. 그렇기 때문에 슈퍼 유저가 아닌 유닉스 및 리눅스를 요구하는 이유도 있습니다 .

편집 : 대답은 다음과 같습니다. mdadm은 데이터 스크럽 중 디스크 시스템에서보고 한 URE 만 수정하고 스크럽 중 자동 비트 썩음을 감지 할 수는 있지만 수정할 수는 없습니까?

솔직히 RAIDZ2 ZFS를 거부한다는 것은 놀라운 일입니다. Linux MD가 아니라는 것을 제외하고 는 거의 완벽하게 귀하의 요구를 충족시키는 것으로 보입니다 . ZFS를 대중에게 전하기 위해 십자군에 있지는 않지만 간단한 사실은 ZFS가 처음 부터 해결 하도록 설계된 문제 중 하나라는 것입니다 . 중복 또는 축소되지 않은 상황에서 오류 감지 및 수정을 제공하기 위해 RAID (모든 "일반"RAID)에 의존하는 것은 위험 해 보입니다. ZFS가 데이터 오류를 올바르게 수정할 수없는 경우에도 최소한 오류를 감지 하고 문제가 있음을 알려서 수정 조치를 취할 수 있습니다.

당신은하지 않습니다 이 는 연습을 권장하지만, ZFS와 함께 정기적으로 전체 스크럽을 할 수 있습니다. ZFS는 디스크에서 읽은 데이터가 데이터를 읽을 때 기록 된 데이터와 일치하는지 확인하고, 불일치하는 경우 (a) 중복성을 사용하여 원본 데이터를 재구성하거나 (b) I / O 오류를보고합니다. 응용 프로그램. 또한 스크러빙은 우선 순위가 낮은 온라인 작업으로, 우선 순위가 높거나 오프라인 일 수있는 대부분의 파일 시스템의 파일 시스템 검사와는 매우 다릅니다. 스크럽을 실행 중이고 스크럽 이외의 다른 작업이 I / O를 수행하려는 경우, 스크럽은 기간 동안 뒷자리를 차지합니다. ZFS 스크럽은 RAID 스크럽 과 파일 시스템 메타 데이터 및 데이터 를 모두 대신 합니다. 무결성 검사는 비트 로트를 감지하기 위해 RAID 어레이를 문지르는 것보다 훨씬 철저합니다 (데이터가 의미가 있는지 여부를 알려주지 않고 RAID 컨트롤러가 올바르게 쓴 것만 알려줍니다).

ZFS 중복성 (RAIDZ, 미러링 등)은 사용하지 않는 디스크 위치를 검사하는 동안 일관성을 검사 할 필요가 없다는 이점이 있습니다. 도구가 할당 블록 체인을 따라 이동하므로 제거 중에 실제 데이터 만 검사됩니다. 이는 비 중복 풀과 동일합니다. "일반적인"RAID의 경우, RAID 컨트롤러 (하드웨어 또는 소프트웨어에 관계없이)가 실제로 어떤 데이터가 관련되어 있는지 알 수 없으므로 모든 데이터 (디스크의 사용되지 않은 위치 포함)를 확인해야합니다.

RAIDZ2 vdev를 사용하면 두 개의 드라이브 중복 가치가 있으므로 다른 드라이브 오류로 인해 실제 데이터 손실이 발생하기 전에 두 개의 구성 드라이브가 모두 실패 할 수 있습니다. 이것은 기본적으로 RAID6과 동일합니다.

ZFS에서는 사용자 데이터와 메타 데이터 모두의 모든 데이터가 체크섬되고 (권장하지 않는 경우를 제외하고 권장되는 경우 제외)이 체크섬은 데이터가 어떤 이유로 든 변경되지 않았 음을 확인하는 데 사용됩니다. 체크섬이 예상 값과 일치하지 않으면 데이터가 투명하게 재구성되거나 I / O 오류가보고됩니다. I / O 오류가보고되거나 스크럽이 손상된 파일을 식별하면 해당 파일의 데이터가 잠재적으로 손상되어 백업에서 해당 파일을 복원 할 수 있다는 사실을 알게됩니다. 전체 어레이 복원이 필요하지 않습니다.

평범한 이중 패리티 RAID도 예를 들어 하나의 드라이브에 장애가 발생하고 하나 이상의 드라이브가 디스크에서 데이터를 잘못 읽는 경우와 같은 상황으로부터 사용자를 보호하지 않습니다. 하나의 드라이브가 고장 나고 다른 드라이브 중 어느 곳에서나 단일 비트 플립이 있다고 가정하십시오. 갑자기 감지되지 않은 손상이 있으며, 만족하지 않으면 최소한 감지 할 수있는 방법이 필요합니다. 이러한 위험을 완화하는 방법은 디스크의 각 블록을 체크섬하고 체크섬이 데이터와 함께 손상되지 않도록하는 것입니다 (고속 쓰기, 고아 쓰기, 디스크의 잘못된 위치에 쓰기 등의 오류 방지). 체크섬이 활성화되어있는 한 ZFS가하는 것입니다.

유일한 단점은 장치를 추가하여 RAIDZ vdev를 쉽게 확장 할 수 없다는 것입니다. 일반적으로 스파 스 파일과 같은 장치를 vdev의 장치로 사용하는 경우가 많으며 "내 데이터 인 경우에는이 작업을 수행하지 않습니다"라고 하는 해결 방법이 있습니다 . 따라서 RAIDZ 경로를 사용하는 경우 (RAIDZ, RAIDZ2 또는 RAIDZ3 사용 여부에 관계없이) 각 vdev에서 원하는 드라이브 수를 미리 결정해야합니다. vdev의 드라이브 수는 고정되어 있지만 드라이브를 대용량 드라이브로 교체하고 완전한 리 실버를 허용하여 점진적으로 (vdev의 중복 임계 값 내에 유지) vdev를 확장 할 수 있습니다.

이 대답은 내가 찾은 다양한 증거를 기반으로 한 추론의 결과입니다. 나는 커널 개발자가 아니기 때문에 커널 리눅스 구현이 어떻게 작동하는지 모르겠다. 커널 리눅스가 제대로 선택했다고 가정합니다. 내가 실수하지 않는 한 내 대답이 적용되어야합니다.

많은 드라이브는 ECC (오류 수정 코드)를 사용하여 읽기 오류를 감지합니다. 데이터가 손상된 경우 커널은 ECC 지원 드라이브에서 해당 블록에 대한 URE (복구 할 수없는 읽기 오류)를 수신해야합니다. 이러한 상황에서 (아래 예외가 있음), 데이터가 손상되었거나 비어있는 상태에서 데이터를 복사하면 광기가 발생할 수 있습니다. 이 상황에서 커널은 어느 것이 좋은 데이터이고 어떤 것이 나쁜 데이터인지 알아야합니다. 에 따르면 그것은 2010 년과 RAID5는 여전히 ... 작동 기사 :

적어도 두 개의 어레이 공급 업체에서 사용하는 것으로 알고있는이 대안을 고려하십시오. RAID 볼륨의 드라이브가 URE를보고하면 어레이 제어기는 패리티에서 블록을 재 구축하여 카운트를 증가시키고 I / O를 충족시킵니다. 그런 다음 URE (잠재적으로 확인)를보고 한 디스크에서 다시 쓰기를 수행하고 섹터가 불량하면 마이크로 코드가 다시 매핑되고 모든 것이 정상입니다.

그러나 이제 예외가 있습니다. 드라이브가 ECC를 지원하지 않거나 드라이브가 데이터 손상에 관한 것이거나 펌웨어가 특히 작동하지 않으면 URE가보고되지 않고 손상된 데이터가 커널에 제공 될 수 있습니다. 데이터가 일치하지 않는 경우 : 2 디스크 RAID1 또는 RAID5를 사용하는 경우 커널은 패리티가 하나도 없기 때문에 성능이 저하되지 않은 상태에서도 어떤 데이터가 올바른지 알 수없는 것 같습니다 차단되었으며보고 된 URE는 없었다. 3 디스크 RAID1 또는 RAID6에서 손상된 단일 URE- 플래그가없는 블록은 중복 패리티 (다른 관련 블록과 함께)와 일치하지 않으므로 적절한 자동 복구가 가능해야합니다.

이야기의 교훈은 ECC와 함께 드라이브를 사용하는 것입니다. 불행히도 ECC를 지원하는 모든 드라이브가이 기능을 광고하는 것은 아닙니다. 반면, 2 디스크 RAID1 (또는 2 사본 RAID10)에서 저렴한 SSD를 사용한 사람을 알고 있습니다. 드라이브 중 하나가 특정 섹터를 읽을 때마다 임의의 손상된 데이터를 반환했습니다. 손상된 데이터는 올바른 데이터로 자동 복사되었습니다. SSD가 ECC를 사용하고 제대로 작동했다면 커널은 적절한 수정 조치를 취해야합니다.

원하는 보호를 위해 RAID6 + 2 개 위치의 일반 오프 사이트 백업을 사용합니다.

어쨌든 개인적으로 일주일에 한 번 스크럽하고 데이터 중요도 및 변경 속도에 따라 야간, 매주 및 매월 백업합니다.

의견을 말할 충분한 담당자가 없지만 Linux의 mdadm 시스템이 오류를 수정하지 않는다는 것을 지적하고 싶습니다. RAID6을 스크러빙하는 동안 오류를 "수정"하도록 지시하면 불일치가있는 경우 데이터 부분이 정확하고 패리티를 다시 계산한다고 가정하여 오류를 "수정"합니다.

비트 부패.? 확실한...

SEAGATE와 대화해야한다고 생각합니다. (잊어? 변명인가?) 이제 드라이브는 모두 먼저 썩음을 증명하는 데 필요한 100 비트 ECC 보정 기능이 있습니다.
당신은 할 수 없습니다 내기. 귀신이나 # 13에 대한 두려움과 같은 (FUD가 걱정해야합니까?) 그리고 여기에서 끝나지 않았습니다. 제로 증거가 발생했습니다. 더 나쁜 원인의 증거.

먼저 비트 썩음의 의미를 정의하십시오.? ouch ... HDD : ECC는 ECC 100 비트 스토리지와 비교하여 데이터 (1 비트조차도)를 확인합니다. 잘못되면 SMART 엔진이 계속 실패하면 SAS 드라이브에서 클러스터 또는 섹터를 논리적으로 대체합니다. 예비 클러스터 사용. 손상이 복구됩니다. 그렇습니다. 모든 드라이브는 IBM의 첫 드라이브에서 NOW에 이르기까지 첫날부터 불량 비트로 커집니다. 하지만 이제 자체 수리를합니다. Seagate 전체 백서를 읽으십시오. 끝없이 드라이브가 작동하는 방법을 배우십시오. 확인?

이것은 당신이 여분의 부족 (hdd brain, smart)이 다 떨어질 때까지 계속되고 SMART는 생명의 끝을 외칩니다. HP P420 컨트롤러에 대해 (또는 HP보다 더 일찍) 항상 이것을 감시합니다. NARE OUT OF SPARE 클러스터를 보여주는 이메일도 있습니다. 언젠가는 여분의 물건이 더 빨리 가고, 곧 운명의 신호가 될 것입니다.

나는 비트 부패에 BOGUS와 FUD를 호출합니다.

내 생각에 누군가 장난감 PC가 어떤 이유로 든 데이터를 잘못 썼다. ECC 메모리를 실행하지 않습니다 ?? 죄송합니다. 실제 서버에는 ECC RAM이 있습니다. 바이러스 감염? 또는 쓰기 도중 전원이 끊겼습니까 (UPS가 아닙니까?)? 또는 나쁜 기억이 있습니까? 또는 ESD 손상. 또는 PSU가 많은 소음을내는 경우 (나쁜)

나는 FUD라고 부릅니다. 죄송합니다,