RAID의 어떤 물리적 드라이브가 OS에서 부여한 소프트웨어 장치 이름과 관련되어 있는지 확실하게 알 수 있는 방법이 있습니까?
PC에 연결된 허브에 소비자급 USB 디스크(및 예비 1개)의 RAID5 배열이 있습니다. 이것은 저렴한 NAS 역할을 합니다.
/proc/mdstat각 장치는 장치 이름(예: sdb, ) 으로 식별됩니다 sdc.
내가 알 수 있듯이 Linux 장치 이름은 부팅 시 하드웨어를 읽는 순서에 따라 달라집니다. 예를 들어, 오늘이 미래 sdc일 수도 있기 때문에 각 드라이브에 해당 장치 이름이 적힌 스티커를 붙여서는 안 됩니다 .sdb
장애 발생 시 RAID를 중지한 후 dmesg -W제거 과정을 통해 장애가 발생한 장치를 제거할 때까지 하나씩 제거하면서 살펴보는 방식으로 현재 장치 이름 매핑을 테스트할 수 있었습니다. 하지만 더 좋은 방법이 있나요?
RAID 멤버를 개별적으로 라벨링할 수는 없습니다. 모두 어레이 이름을 공유해야 합니다.https://wiki.archlinux.org/title/pertant_block_device_naming#by-label
나는 보았다ledctl 소비자 드라이브에서는 작동하지 않습니다.https://linux.die.net/man/8/ledctl
답변1
lsblk -S각 장치를 디스크의 일련 번호(또는 추가하는 경우 WWN)에 매핑하는 데 사용됩니다 -o +wwn.
USB 허브 경로는 물리적 USB 포트에 의해 표시 lsusb.py -ci되거나 이에 대한 고정 매핑을 가져야 합니다. 예를 들어 내 서버의 "1-1.1" 및 "1-1.2"는 전면 패널 포트에 연결되어 있습니다. udevadm info /dev/sdd | grep ID_PATH=외부 허브의 포트 순서가 항상 명확하지는 않지만 일단 파악한 후에는 여전히 고정된 상태로 유지되어야 합니다.
LED 대안: sg3_utils의 scsi_start/ scsi_stop스크립트는 필요에 따라 HDD를 회전시키거나 회전시킬 수 있습니다(실제로 연결을 끊지 않고). 어레이가 유휴 상태인 경우 모든 디스크를 중지하고 모든 엔클로저가 HDD 일련 번호와 일치할 때까지 하나씩 회전시킵니다.
답변2
UUID_SUB나는 답변을 썼지만 이후 lsblk 값을 사용하는 것이 해결책이 아니라는 것을 알게 되었습니다 . 최근 디스크 장애 이벤트를 통해 UUID_SUB처음 생각했던 것처럼 디스크 파티션의 슈퍼블록에 연결되지 않은 것 같습니다.
따라서 나는 원래 답변을 없애고 다른 사람들에게 투표하여 삭제하도록 맡길 것입니다.
현재까지 이 질문에 대해 입증된 유일한 대답은 다를 수 있는 외부 인클로저가 아닌 드라이브 케이스 자체에 일련 번호가 표시되는 베어 디스크를 사용하는 것입니다. 그런 다음 lsbk -S장애 발생 시 어떤 물리적 드라이브를 처리해야 하는지 알아내는 데 사용합니다 .