나는히드라 LCD 모듈베이 4개가 있는 RAID 장치(2TB Hitachi 4개). 저는 2010년부터 RAID5 모드로 실행해왔습니다. 지난 5월, 장치는 드라이브 성능이 저하되었으므로 교체해야 한다는 메시지를 보내기 시작했습니다. 저도요. 한 달 후 두 번째 드라이브에서 다운그레이드 메시지가 표시되었습니다. 그래서 이것도 바꿨어요.
두 번째 드라이브가 성공적으로 복원된 후 모든 것이 정상적으로 실행되는 것처럼 보였습니다. 며칠 후 스토리지 박스의 전원을 다시 켰을 때 갑자기 더 이상 RAID 모드가 감지되지 않습니다. 디스플레이에 디스크나 모드를 초기화하지 않았다고 표시됩니다.
이 장치가 단종되었기 때문에(2015년 이후인 것 같아요) 정말 당황스럽습니다. 제조업체에서 "표준 RAID 기술"을 사용하여 일부 소프트웨어 RAID 대안(예: )을 사용하여 mdadm이 하드웨어 RAID를 복구 할 수 있기를 바랍니다.
내부에도움이 되었기를 바랍니다:
Hydra Super-S LCM 내부의 RAID 컨트롤러는 역방향 패리티 회전을 사용하고 RAID 스트라이프는 512개 섹터이므로 모든 디스크에 균형 잡힌 방식으로 액세스되며 패리티 디스크에 추가 워크로드가 없습니다.
mdadmRAID5 또는 이와 유사한 것을 사용하여 이 특정 하드웨어를 복원할 가능성이 있는지 아는 사람이 있습니까 ?
그런데. 또 다른 문제는 디스크가 특정 OSX 파일 시스템으로 포맷되었다는 것입니다. 그러나 일부 USB3 디스크 리더가 준비되어 있으며 현재 Ubuntu에 연결되어 있습니다. 이 어댑터는 4개의 드라이브를 동시에 연결할 수 있습니다. mdadm기존 파일 시스템 테이블이나 RAID 정보(또는 나머지 정보)를 덮어쓸까 봐 이와 같은 작업을 실행하는 것이 두렵습니다 . 어떤 조언이라도 높이 평가하겠습니다.
답변1
읽기 전용 모드에서 실험을 실행해야 합니다.
RAID 레이아웃을 재현하려는 순진한 시도:
# mdadm --create /dev/md100 --assume-clean --metadata=0.90 --level=5 --chunk 256K --raid-devices=4 /dev/loop[0123]
추적 데이터로 덮어씁니다(데이터 = 16진수 오프셋).
# for ((i=0; 1; i+=16)); do printf "%015x\n" $i; done > /dev/md100
# hexdump -C /dev/md100
00000000 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0a |000000000000000.|
00000010 30 30 30 30 30 30 30 30 30 30 30 30 30 31 30 0a |000000000000010.|
00000020 30 30 30 30 30 30 30 30 30 30 30 30 30 32 30 0a |000000000000020.|
00000030 30 30 30 30 30 30 30 30 30 30 30 30 30 33 30 0a |000000000000030.|
이 레이아웃에서 블록은 어디에 있습니까?
# grep -ano $(printf "%015x" $((0 * 512*512))) /dev/loop[0123]
/dev/loop0:1:000000000000000 # Disk A 1
# grep -ano $(printf "%015x" $((1 * 512*512))) /dev/loop[0123]
/dev/loop1:1:000000000040000 # Disk B 2
# grep -ano $(printf "%015x" $((2 * 512*512))) /dev/loop[0123]
/dev/loop2:1:000000000080000 # Disk C 3
# grep -ano $(printf "%015x" $((3 * 512*512))) /dev/loop[0123]
/dev/loop3:16385:0000000000c0000 # Disk D 4
# grep -ano $(printf "%015x" $((4 * 512*512))) /dev/loop[0123]
/dev/loop0:16385:000000000100000 # Disk A 5
그래서 이것은 가깝지만 사진이 보여주는 것과 정확히 같지는 않습니다. 이것은 RAID 레이아웃의 문제입니다. 마운트할 수도 있을 만큼 유사할 수 있지만 몇 개의 블록만 순서가 잘못되었기 때문에 파일에 이상한 손상이 표시될 수 있습니다.
mdadm기본 4개 디스크 RAID5 레이아웃을 사용하면 left-symmetric처음 4개 블록을 읽는 경우 실제로는 4개 디스크에서 해당 블록을 읽는 것입니다. 표시된 레이아웃에서는 블록 4가 다시 네 번째 디스크가 아닌 첫 번째 디스크에 있으므로 3개의 디스크에서 읽습니다.
따라서 이미지를 일치시키려면 다른 레이아웃을 시도해야 합니다.
같이 가자 left-asymmetric.
# mdadm --create /dev/md100 --assume-clean --metadata=0.90 --level=5 --layout=left-asymmetric --chunk 256K --raid-devices=4 /dev/loop[0123]
# for ((i=0; 1; i+=16)); do printf "%015x\n" $i; done > /dev/md100
# mdadm --stop /dev/md100
# echo 3 > /proc/sys/vm/drop_caches
# for i in {0..23}; do grep -ano $(printf "%015x" $(($i * 512*512))) /dev/loop[0123]; done
출력(더 나은 이해를 위해 추가된 설명):
/dev/loop0:1:000000000000000 # Disk A 1
/dev/loop1:1:000000000040000 # Disk B 2
/dev/loop2:1:000000000080000 # Disk C 3
# skips parity loop3
/dev/loop0:16385:0000000000c0000 # Disk A 4
/dev/loop1:16385:000000000100000 # Disk B 5
# skips parity loop2
/dev/loop3:16385:000000000140000 # Disk D 6
/dev/loop0:32769:000000000180000 # Disk A 7
# skips parity loop1
/dev/loop2:32769:0000000001c0000 # Disk C 8
/dev/loop3:32769:000000000200000 # Disk D 9
# skips parity loop0
/dev/loop1:49153:000000000240000 # Disk B 10
/dev/loop2:49153:000000000280000 # Disk C 11
/dev/loop3:49153:0000000002c0000 # Disk D 12
/dev/loop0:65537:000000000300000 # Disk A 13
/dev/loop1:65537:000000000340000 # Disk B 14
/dev/loop2:65537:000000000380000 # Disc C 15
# skips parity loop3
/dev/loop0:81921:0000000003c0000 # Disk A 16
/dev/loop1:81921:000000000400000 # Disk B 17
# skips parity loop2
/dev/loop3:81921:000000000440000 # Disk D 18
/dev/loop0:98305:000000000480000 # Disk A 19
# skips parity loop1
/dev/loop2:98305:0000000004c0000 # Disk C 20
/dev/loop3:98305:000000000500000 # Disk D 21
# skips parity loop0
/dev/loop1:114689:000000000540000 # Disk B 22
/dev/loop2:114689:000000000580000 # Disk C 23
/dev/loop3:114689:0000000005c0000 # Disk D 24
이 레이아웃이 귀하의 이미지와 더 잘 어울리는 것 같습니다. 아마도 효과가 있을 것입니다. 행운을 빌어요.