/dev에서 불량 드라이브가 사라지는 것을 방지할 수 있는 방법이 있습니까?

/dev에서 불량 드라이브가 사라지는 것을 방지할 수 있는 방법이 있습니까?

손상된 드라이브의 파티션을 복구하기 위해 ddrescue를 사용하려고 합니다. 난 달린다:

$ sudo ddrescue -r -1 -v /dev/sdd3 OUT.img dd_rescue_logfile

잠시 동안은 잘 작동하는 것처럼 보였지만 약 한 시간 후에 드라이브가 /dev에서 사라졌기 때문에 "현재 속도"가 0으로 떨어졌습니다. 드라이브를 복구하기 위해 제가 생각할 수 있는 유일한 방법은 시스템을 재부팅하고 ddrescue 명령을 실행하여 중단된 부분부터 다시 시작하는 것이었습니다. 이로 인해 프로그램을 실행하기가 매우 어려워집니다. 그냥 놔두고 며칠 동안 잊어버릴 수 없기 때문입니다. 디스크가 사라지지 않도록 지속적으로 모니터링해야 합니다. 저는 Arch Linux와 Fedora 22 모두에서 이 동작을 보았습니다.

나는 어느 시점에서 커널이 드라이브에 대한 액세스를 잃고 /dev에서 드라이브를 제거한다고 가정합니다. 이것을 피할 수 있는 방법이 있나요? 장치가 손상된 것처럼 보이거나 존재하지 않는 경우에도 장치를 그대로 유지하도록 커널에 지시하시겠습니까?

답변1

올바른 모듈을 언로드/다시 로드하면(또는 드라이버를 바인딩 해제했다가 다시 바인딩하면) 재부팅하지 않고도 다시 검색할 수 있습니다.

예를 들어:

[  978.527221] sd 11:0:0:1: [sdk] Attached SCSI removable disk
#~> echo 11:0:0:1 > /sys/bus/scsi/drivers/sd/unbind
#~> echo 11:0:0:1 > /sys/bus/scsi/drivers/sd/bind
[ 5572.027119] sd 11:0:0:1: [sdk] Attached SCSI removable disk

또는 이 방법이 작동하지 않고 동일한 컨트롤러에 연결된 다른 장치가 없는 경우 /sys/bus/pci/drivers/ahci/예를 들어 AHCI를 통해 전체 컨트롤러를 바인딩 해제하고 바인딩할 수 있습니다.

실제로 작동하는지 테스트할 결함이 있는 드라이브가 없지만 이전에 이 방법을 사용하여 기본적으로 핫 스왑이 불가능한 슬롯에서 MicroSD/MMC 카드를 강제로 다시 감지한 적이 있습니다.

ddrescue속도를 0으로 줄이는 경우 해당 -a, --min-read-rate=<bytes>옵션을 지원하는지 확인하고 싶을 수도 있습니다. 느린 영역을 결함으로 처리하고 건너뜁니다. 최악의 시나리오는 외부에서 디스크를 모니터링하고 강제로 재부팅해야 하는 것입니다 ddrescue.

답변2

USB2NVME 어댑터를 사용하고 있으며 USB 어댑터를 뽑았다가 다시 연결하기만 하면 장애가 발생한 드라이브를 몇 초 만에 재부팅할 수 있습니다.

즉, NVME 드라이브를 직접 냉각(12V 팬 사용)하면 드라이브가 더 이상 사라지지 않는다는 사실을 발견했습니다. 드라이브를 식힌 순간부터 ddrescue더 이상 나타나지 않습니다 ddrescue: Input file disappeared: No such file or directory.

답변3

/dev/sdx또한 부팅 직후 소스 장치가 사라지는 경우가 ddrescue있었고 SATA 드라이브를 시스템에 연결하는 데 사용한 USB "토스터"를 뽑았다가 다시 삽입하면 재부팅이 발생한다는 것을 알고 있습니다.

ddrescue를 다시 시작하면 몇 분 동안 실행된 후 곧 충돌이 발생합니다. 를 사용하면 lsblk드라이브가 연결되어 있는지 쉽게 확인할 수 있습니다. 어쨌든, 나는 1 Ubuntu 시스템에서 ddrescue를 몇 번 실행한 다음 ddrescue가 약간 더 오래된(1.23) 최신 19.04 Ubuntu에서 몇 번 더 실행했습니다.

위와 다른 곳에서 언급한 바인드/바인드 해제 해결 방법을 시도한 후에도 여전히 문제가 발생하여 CentOS 7 시스템(CentOS Linux 버전 7.7.1908(코어))에서 ddrescue 버전 1.24를 사용하여 ddrescue를 실행해 보면 kernel 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux성공할 것이라고 생각했습니다!

드라이브가 실행될 때(/var/log/messages에 따라) 많은 오류가 발생하지만 이 시점에서 10시간 이상 실행되었으며 단일 하드 드라이브 인스턴스가 사라지지 않았습니다.

제가 CentOS를 다시 시도하게 된 것은 몇 년 전에도 비슷한 복구 상황을 겪었고 당시 제가 사용하고 있던 CentOS 6 시스템에서는 드라이브가 손실되지 않았다는 사실을 발견했기 때문입니다.

도움이 되었기를 바랍니다.

관련 정보