내 소프트웨어 RAID1 슈퍼 블록이 계속 손상되는 이유는 무엇이며 이러한 일이 발생하지 않도록 하려면 어떻게 해야 합니까?

내 소프트웨어 RAID1 슈퍼 블록이 계속 손상되는 이유는 무엇이며 이러한 일이 발생하지 않도록 하려면 어떻게 해야 합니까?

RAID1의 슈퍼블록이 반복적으로 손상될 수 있는 방법은 무엇입니까?

지난 6개월 동안 두 번이나 슈퍼블록 문제로 인해 RAID1 루트 어레이를 사용할 수 없게 되었습니다. 불행히도 처음에는 좋은 메모를 하지 못했지만 슈퍼 블록과 나쁜 마법에 문제가 있었습니다. 최근에 발생한 것처럼 호스트가 정지되었을 때 일부 KVM VM을 종료하고 강제로 재부팅한 다음 슈퍼블록 매직 오류와 함께 inramfs 프롬프트로 부팅했습니다.

설치 복원을 포기하고 나에게 적합한 방법(미러링된 LVM의 아치)으로 돌아갈 준비가 되었지만 왜 이런 일이 발생하는지 알고 싶습니다. 내가 파티션을 잘못된 방식으로 구성했나요? 하드웨어 RAID가 없으면 충돌이나 강제 재부팅으로 인해 슈퍼블록이 손상될 수 있다고 가정해야 합니까? 잘못된 결과인가요? 그렇다면 mdadm, 배포판, KVM에 있을 수 있습니까? 아니면 철저한 테스트 없이는 추측이 불가능합니까?

현재 충돌에서 관련 오류는 다음과 같습니다.

md1: invalid bitmap file for superblock: bad magic
md1: failed to create bitmap (-22)

이것이 내가 시작한 일이다

Gparted 복구 디스크로 부팅하면 md1은 없지만 md125(3개 중 가장 작은 ID 번호)가 있습니다. gparted 응용 프로그램에는 표시되지 않지만 /dev/md125에서 볼 수 있으며 실행하면 sudo mdadm --detail /dev/md125활성화되어 있고 실패했으며 시작되지 않았음을 나타내는 출력이 표시됩니다. 또한 "슈퍼블록은 일관성이 있다"

나는 또한 다음을 시도했습니다.

e2fsck -b 8193 /dev/sda2
e2fsck -b 8193 /dev/sdb2
e2fsck -b 32768 /dev/sda2
e2fsck -b 32768 /dev/sdb2

"수퍼블록의 잘못된 매직 넘버"라는 출력이 나올 때마다

이는 어레이에서 손상이 복제되었음을 의미합니까? 그렇다면 이런 일이 발생하지 않도록 할 수 있을까요?

세부 사항:

  1. 이는 각각 별도로 구매한 서로 다른 두 쌍의 드라이브에서 발생합니다.
  2. 드라이브는 첫 번째 손상 사건 이후 몇 달 동안 LVM에서 잘 작동했습니다. 해당 시스템(Arch)을 철거했을 때 문제가 있어서가 아니라 Ubuntu Server와 RAID1을 다시 시도하고 싶었습니다.
  3. 컴퓨터에는 전력 변동을 방지하기 위해 UPS가 연결되어 있는데, 저는 이를 얻었습니다. 불행하게도 전원 공급 장치는 접지되어 있지 않지만 이것이 전력 서지에 중요하고 제가 있는 곳에서는 큰 문제가 아니라는 것을 알고 있습니다.
  4. Ubuntu Server 18.04.2에서 문제가 발생했습니다. 그 동안에는 동일한 드라이브에서 LVM과 함께 Arch를 아무런 문제 없이 사용하고 있었습니다.
  5. memtest를 몇 번 실행했는데 오류가 발생하지 않았습니다.
  6. ECC RAM(버퍼되지 않음)이 있습니다.
  7. 시스템은 x399 Taichi 마더보드의 Ryzen Threadripper 1950x입니다.

요점은 드라이브 오류에 대한 복원력을 제공하여 가동 시간을 극대화하는 것이었지만, 그 대신 드라이브는 물리적으로 양호하지만 RAID1 슈퍼 블록이 어떻게든 손상되었기 때문에 가동 시간을 잃는 것 같습니다. 이것이 RAID1에서 부팅할 때 내재된 위험입니까?

편집: 실행하면 mdadm --detail /dev/mdX다음과 같은 결과가 나타납니다. initramfs 쉘의 mdadm

편집 2: 또한 initramfs에서 /etc/mdadm/mdadm.conf는 다음과 같습니다. initramfs의 mdadm.conf

Edit3: 이 문제는 간헐적으로 발생하는 것 같습니다. Gparted로 부팅했는데 문제가 되는 md 장치를 한 번 볼 수 있었고 정상으로 돌아왔지만 재부팅 후 다시 성능이 저하되었습니다.

편집 4: gparted에서 어레이를 중지한 다음 gparted로 재부팅하면 장치를 백업하고 정상으로 표시할 수 있는 것 같습니다(그러나 설치를 부팅하려고 하면 여전히 손상됩니다).

Edit5: 위의 내용은 거짓 긍정입니다. 단지 md125가 이제 정상적인 파티션 중 하나인 반면, 문제의 파티션은 md126이 되어 여전히 성능이 저하되어 있습니다.

Edit6: 배열 조립을 중단하면mdadm: failed to RUN_ARRAY /dev/md126: Invalid argument RUN_ARRAY 실패

관련 정보