mdadm raid6의 6개 드라이브는 모두 제대로 작동하지만 시스템 업데이트 중 selinux가 액세스를 차단한 후 실패로 표시됩니다.

mdadm raid6의 6개 드라이브는 모두 제대로 작동하지만 시스템 업데이트 중 selinux가 액세스를 차단한 후 실패로 표시됩니다.

따라서 시스템 로그에 따르면 최근 내 시스템에서 dnf를 업데이트하는 동안 selinux는 어느 시점에서 갑자기 커널에 대한 쓰기 액세스를 비활성화한 다음 RAID 드라이브를 "실패"로 표시했습니다.

fstab에서 문제가 되는 raid 드라이브를 제거하여 시스템을 다시 실행했습니다. (새 커널이 있어서 재부팅했는데 raid 드라이브가 갑자기 작동을 멈췄다는 사실을 몰랐습니다.)

그래서 모든 것이 괜찮아 보였지만 RAID 드라이브가 "부팅"되지 않아서

for x in a b c d e f; do 
    mdadm --examine /dev/sd${x}1 > mdstats.$x; 
    done

그런 다음 mdstats.x 파일에서 각 raid 요소의 상태를 확인합니다. 모든 장치가 "깨끗함"으로 표시되고 모두 정확히 동일한 수의 "이벤트"를 갖기 때문에 이는 실제로 좋은 소식입니다.

명령줄에서 RAID 장치의 상태를 보려면 다음을 수행했습니다.

% cat /proc/mdstat
Personalities : 
md127 : inactive sdf1[3] sde1[0] sda1[6] sdb1[5] sdd1[1] sdc1[4]
      17581198678 blocks super 1.2
       
unused devices: <none>

뭔가 놓친 경우를 대비해 mdadm --examine 출력을 모두 포함하겠습니다. 하지만 모두 비슷해 보입니다.

  % mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
           Name : LostCreek:0
  Creation Time : Wed Mar 25 11:56:03 2020
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 5860399104 sectors (2.73 TiB 3.00 TB)
     Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
  Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
    Data Offset : 131072 sectors
   Super Offset : 8 sectors
   Unused Space : before=130992 sectors, after=133120 sectors
          State : clean
    Device UUID : 100e1983:e323daa4:a28faf75:68afde64

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug  5 03:45:48 2022
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : f6f4c925 - correct
         Events : 128119

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

그리고 비교해보세요:

   % mdadm --examine /dev/sdf1
/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
           Name : LostCreek:0
  Creation Time : Wed Mar 25 11:56:03 2020
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 5860400015 sectors (2.73 TiB 3.00 TB)
     Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
  Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
    Data Offset : 131072 sectors
   Super Offset : 8 sectors
   Unused Space : before=130992 sectors, after=134031 sectors
          State : clean
    Device UUID : 8a99c085:51469860:99f42094:5dea9904

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug  5 03:45:48 2022
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 73871a85 - correct
         Events : 128119

         Layout: left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

6개 장치 모두 사이의 유일한 다른 회선은 다음과 같습니다.

 1. /dev/sda1 
 11. Avail Dev Size
 16. Unused Space
 18. Device UUID : 100e1983:e323daa4:a28faf75:68afde64
 23. Checksum : f6f4c925 - correct
 29. Device Role : Active device 3

선행 숫자는 이 기사 상단에 있는 for 루프를 사용하여 생성된 파일의 줄 번호입니다.

   vimdiff mdstat.?

"업데이트 시간", "이벤트" 등이 모두 일치합니다. 장치 역할 행(다르게 표시된 마지막 항목)은 0부터 5까지 모두 다릅니다.

이 모든 것이 제대로 작동하는 것처럼 보이지만 인터넷 검색을 많이 한 후에 다시 기능을 수행하려면 다음 명령을 사용해야 한다고 생각합니다.

mdadm --create /dev/md127 --level=6 --raid-devices=6 --chunk=512 --name=LostCreek:0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 --assume-clean

이 부분은 다음 질문/답변에서 나온 것입니다.MDADM - 재해 복구 또는 계속 진행..그리고mdadm은 디스크를 예비 디스크로 다시 추가합니다..

나는 이것을 시도하려고했지만 내가 놓친 것이 있는지 확인하고 싶었습니다. 또한 실제로 실패한 드라이브가 없는 유사한 문제를 본 적이 없지만 소프트웨어 공격대에서 쓰기를 중지하여 selinux를 "저장하도록 허용"합니다. (내 selinux는 "허용" 상태에 있었고 안전하다고 생각했지만 지금은 "비활성화" 상태입니다).

이것이 다른 사람들에게 유용하길 바랍니다. 특히 그것이 "작동"한다면 더욱 그렇습니다. 이러한 문제는 드문 것으로 보이며 내 자신의 질문에 답변하고 싶지만 실제로 한 달 된 백업에서 전체 공격대를 복원하고 싶지는 않습니다. (예, 언제나 그렇듯이 더 자주 백업해야 하지만 다행히 백업을 잃는다고 해서 세상이 끝나는 것은 아닙니다.)

건배

마이크로폰

답변1

아아! , 내 말은 우후!

돌아왔다! 그리고 프로스트츄츠, 언젠가 맥주나 저녁을 사줄 수 있다면 기꺼이 그렇게 할게요!

상황이 어떻게 진행되었는지 위의 내 의견을 참조하세요. 하지만 Frostshutz의 답변과 mdadm --examine 에서 얻은 내용을 사용하여 다음을 수행하고 이제 돌아왔습니다!

--size를 추가하고 mdadm --examine 출력의 "Role" 줄에 지정된 순서대로 장치를 배치하는 명령은 다음과 같습니다.

mdadm --stop /dev/md127

mdadm --create /dev/md42 --assume-clean \
    --level=6 --chunk=512K --metadata=1.2 --data-offset=131072s \
    --size=2930132992K \
    --raid-devices=6 /dev/sde1 /dev/sdd1 /dev/sdf1 /dev/sda1 /dev/sdb1 /dev/sdc1

오류 메시지가 포함된 raid는 md127에 있습니다. /dev/md42가 이 모든 스핀 이전에 제가 가지고 있던 raid 장치였으면 좋겠습니다. RAID 장치는 암호화된 디스크이며 포맷됩니다. 나는 mdadm --examine 비트(동일한 for 루프 사용)를 보고 이전에 가지고 있던 것과 비교했는데 금이거나 금인 것처럼 보입니다. 이제 "역할", 크기 등이 일치합니다. 분명히 "이벤트"는 없지만 예상했던 것만 큼 좋아 보입니다. 그렇다면 결정적인 순간은

cryptsetup luksOpen /dev/md42 woot

보라, 나는 /dev/mapper/woot 장치를 가지고 있다. 그것은 올라갔고, 세상 모든 것이 순조롭게 진행되었습니다.

매우 감사합니다. 그렇지 않다면 이 지점에 도달하는 것은 불가능할 것이다. Frostschutz는 이를 수행하는 방법을 매우 명확하게 설명합니다.. 정말 신난다! 새로운 백업을 시작하겠습니다.

관련 정보