Evitar que o armazenamento USB use dispositivos diferentes ao reinicializar

Question

Eu tenho um disco rígido em um gabinete USB em que estou recuperando dados. A unidade está em péssimo estado e frequentemente é redefinida nas leituras.

O dispositivo registra como /dev/sdb . Às vezes, provavelmente cerca de uma vez a cada mil reinicializações, por algum motivo, ela passa para /dev/sdc . A única maneira de fazê-lo voltar é desconectar fisicamente a conexão USB por alguns segundos e depois reconectá-la, no ponto em que ela é registrada como /dev/sdb novamente.

Isso é muito perturbador e causa muitos problemas para mim, já que algumas das operações que estou realizando podem levar horas ou dias, e se isso acontecer em qualquer momento desse processo (por exemplo, enquanto estou no trabalho ou dormindo) ) Eu tenho que tentar determinar quando aconteceu e retomar a partir desse ponto, ou começar de novo. Ambos são muito difíceis.

Um conjunto "normal" de redefinições, que espero e estão corretas, é assim:

Jun 12 11:15:28 ubuntu kernel: [199944.703449] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:29 ubuntu kernel: [199945.574141] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:29 ubuntu kernel: [199946.017483] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:30 ubuntu kernel: [199946.460816] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:30 ubuntu kernel: [199946.904151] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:30 ubuntu kernel: [199947.347659] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:31 ubuntu kernel: [199947.690737] sd 16:0:0:0: [sdb] Unhandled error code
Jun 12 11:15:31 ubuntu kernel: [199947.690747] sd 16:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jun 12 11:15:31 ubuntu kernel: [199947.690757] sd 16:0:0:0: [sdb] CDB: Read(10): 28 00 00 01 1d cd 00 00 01 00
Jun 12 11:15:31 ubuntu kernel: [199947.690780] end_request: I/O error, dev sdb, sector 73165
Jun 12 11:15:35 ubuntu kernel: [199951.585312] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:36 ubuntu kernel: [199952.455995] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:36 ubuntu kernel: [199952.899329] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:36 ubuntu kernel: [199953.342669] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:37 ubuntu kernel: [199953.786009] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:37 ubuntu kernel: [199954.229346] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 11:15:38 ubuntu kernel: [199954.572710] sd 16:0:0:0: [sdb] Unhandled error code
Jun 12 11:15:38 ubuntu kernel: [199954.572721] sd 16:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jun 12 11:15:38 ubuntu kernel: [199954.572730] sd 16:0:0:0: [sdb] CDB: Read(10): 28 00 00 01 1d cd 00 00 01 00
Jun 12 11:15:38 ubuntu kernel: [199954.572754] end_request: I/O error, dev sdb, sector 73165

Esse é o comportamento esperado. Uma redefinição problemática, que muda para sdc , é assim:

Jun 12 12:57:42 ubuntu kernel: [206070.288681] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 12:57:43 ubuntu kernel: [206070.732013] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 12:57:43 ubuntu kernel: [206071.175603] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 12:57:44 ubuntu kernel: [206071.618695] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 12:57:44 ubuntu kernel: [206072.062224] usb 1-1.2: reset high-speed USB device number 23 using ehci_hcd
Jun 12 12:57:44 ubuntu kernel: [206072.095010] usb 1-1.2: USB disconnect, device number 23
Jun 12 12:57:44 ubuntu kernel: [206072.098317] scsi 16:0:0:0: rejecting I/O to offline device
Jun 12 12:57:44 ubuntu kernel: [206072.098327] scsi 16:0:0:0: [sdb] killing request
Jun 12 12:57:44 ubuntu kernel: [206072.098345] scsi 16:0:0:0: [sdb] Unhandled error code
Jun 12 12:57:44 ubuntu kernel: [206072.098349] scsi 16:0:0:0: [sdb]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jun 12 12:57:44 ubuntu kernel: [206072.098356] scsi 16:0:0:0: [sdb] CDB: Read(10): 28 00 03 66 90 8b 00 00 01 00
Jun 12 12:57:44 ubuntu kernel: [206072.098387] end_request: I/O error, dev sdb, sector 57053323
Jun 12 12:57:44 ubuntu kernel: [206072.309890] usb 1-1.2: new high-speed USB device number 26 using ehci_hcd
Jun 12 12:57:45 ubuntu mtp-probe: checking bus 1, device 26: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2"
Jun 12 12:57:45 ubuntu mtp-probe: bus: 1, device: 26 was not an MTP device
Jun 12 12:57:45 ubuntu kernel: [206072.755377] scsi17 : usb-storage 1-1.2:1.0
Jun 12 12:57:46 ubuntu kernel: [206074.240443] scsi 17:0:0:0: Direct-Access     HTS72101 0G9SA00               PQ: 0 ANSI: 6
Jun 12 12:57:46 ubuntu kernel: [206074.242675] sd 17:0:0:0: Attached scsi generic sg2 type 0
Jun 12 12:57:46 ubuntu kernel: [206074.243800] sd 17:0:0:0: [sdc] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)

O problema começa com uma desconexão USB em vez de uma redefinição. Esse é o problema que preciso evitar.

Eu gostaria de forçá-lo de alguma forma a ficar em /dev/sdb . Existe alguma maneira de fazer isso?

Como alternativa, embora pareça que este tipo de reinicialização for inevitável, existe alguma configuração em algum lugar que eu possa mudar temporariamente para evitar que isso aconteça? Algum tempo de repetição ou algo assim? Ou talvez uma maneira de forçar o /dev/sdb a se tornar disponível novamente imediatamente para que seja reutilizado?

O aplicativo que estou executando no momento abre o dispositivo uma vez no início e o mantém aberto o tempo todo durante a tentativa de recuperação. Eu escrevi este aplicativo e posso controlar seu comportamento, portanto, uma solução em código também é uma possibilidade, mas gostaria de ver se há uma solução em nível de sistema primeiro (ainda não tentei uma solução de software, quero ver se existe uma maneira mais fácil).

Eu também me pergunto se talvez seja um problema de energia, embora eu não veja nenhum problema relacionado à energia no log. Eu não tentei um hub com energia ainda. A máquina é um Lenovo ThinkPad T520 (rodando com energia CA) que nunca falhou em termos de corrente USB disponível no passado.

O sistema é Ubuntu 12.04 LTS, kernel 3.2.0-64, 64 bits.

    

Answer 1

Acesse o dispositivo pelos caminhos / dev / disk / by-xxx.

Esses caminhos permanecem os mesmos para o dispositivo / partição, com links simbólicos para o próprio dispositivo / dev / sdXY, mantido pelo sistema. Portanto, embora o dispositivo possa se reconectar a outro dispositivo virtual , o caminho que você pode usar não muda.

/ dev / disk / by-uuid /

• Cada unidade / dispositivo tem um UUID exclusivo, portanto, usar um caminho baseado nele é sempre o mesmo, independentemente de qual dispositivo ele leva. Por exemplo, meu sistema:

  xenon-lornix:/> ll /dev/disk/by-uuid/
  total 0
  lrwxrwxrwx 1 root root 10 Jun 10 02:33 24c80c49-3f88-4343-9b91-c34087e49102 -> ../../sda5
  lrwxrwxrwx 1 root root 10 Jun 10 02:33 b2254550-cc90-46e4-a84f-cb32bca8f83d -> ../../sda1
  

• O caminho /dev/disk/by-uuid/b2254550-cc90-46e4-a84f-cb32bca8f83d sempre apontará para a partição 1 dessa unidade, independentemente de ser sda / sdb / sdc, etc.

Existem outros métodos disponíveis também:

/ dev / disk / by-label /

    xenon-lornix:/> ll /dev/disk/by-label/
    total 0
    lrwxrwxrwx 1 root root 10 Jun 10 02:33 swap -> ../../sda5
    lrwxrwxrwx 1 root root 10 Jun 10 02:33 xenon -> ../../sda1

Sempre rotulo minhas partições, simplifica o arquivamento / uso / montagem de uma unidade específica, em vez de questionar se / dev / sdc é o WD 1TB ou o Samsung 2TB ou o flash drive de 1GB.

Também facilita a montagem: (de / etc / fstab )

    LABEL=xenon   /   ext4   defaults,... and so forth

O caminho by-path pode ser útil, já que associa tecnicamente uma conexão física a um dispositivo específico, talvez útil para você se a unidade não funcionar bem com informações de partição adequadas, dando rótulos estranhos ou algo assim.