У меня есть жесткий диск в корпусе USB, на котором я восстанавливаю данные. Диск в очень плохом состоянии и часто сбрасывается при чтении.
Устройство регистрируется как /dev/sdb. Иногда, вероятно, примерно раз в несколько тысяч сбросов, по какой-то причине оно переключается на /dev/sdc. Единственный способ вернуть его обратно — физически отключить USB-соединение на несколько секунд, а затем снова подключить, после чего оно /dev/sdbснова регистрируется как .
Это очень мешает и создает для меня массу проблем, так как некоторые операции, которые я выполняю, могут занимать часы или дни, и если это происходит в какой-либо момент этого процесса (например, пока я на работе или сплю), мне нужно либо попытаться определить,когдаэто произошло и возобновить с этого момента, или начать заново. И то, и другое очень сложно.
«Нормальный» набор сбросов, который я ожидаю и который приемлем, выглядит так:
12 июня 11:15:28 ядро ubuntu: [199944.703449] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:29 ядро ubuntu: [199945.574141] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:29 ядро ubuntu: [199946.017483] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:30 ядро ubuntu: [199946.460816] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:30 ядро ubuntu: [199946.904151] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:30 ядро ubuntu: [199947.347659] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:31 ядро ubuntu: [199947.690737] sd 16:0:0:0: [sdb] Необработанный код ошибки 12 июня 11:15:31 ядро ubuntu: [199947.690747] sd 16:0:0:0: [sdb] Результат: hostbyte=DID_ERROR driverbyte=DRIVER_OK 12 июня 11:15:31 ядро ubuntu: [199947.690757] sd 16:0:0:0: [sdb] CDB: Чтение(10): 28 00 00 01 1d cd 00 00 01 00 12 июня 11:15:31 ядро ubuntu: [199947.690780] end_request: ошибка ввода-вывода, dev sdb, сектор 73165 12 июня 11:15:35 ядро ubuntu: [199951.585312] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:36 ядро ubuntu: [199952.455995] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:36 ядро ubuntu: [199952.899329] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:36 ядро ubuntu: [199953.342669] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:37 ядро ubuntu: [199953.786009] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:37 ядро ubuntu: [199954.229346] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 11:15:38 ядро ubuntu: [199954.572710] sd 16:0:0:0: [sdb] Необработанный код ошибки 12 июня 11:15:38 ядро ubuntu: [199954.572721] sd 16:0:0:0: [sdb] Результат: hostbyte=DID_ERROR driverbyte=DRIVER_OK 12 июня 11:15:38 ядро ubuntu: [199954.572730] sd 16:0:0:0: [sdb] CDB: Чтение(10): 28 00 00 01 1d cd 00 00 01 00 12 июня 11:15:38 ядро ubuntu: [199954.572754] end_request: ошибка ввода-вывода, dev sdb, сектор 73165
Это ожидаемое поведение. Проблемный сброс, который переключается на sdc, выглядит так:
12 июня 12:57:42 ядро ubuntu: [206070.288681] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 12:57:43 ядро ubuntu: [206070.732013] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 12:57:43 ядро ubuntu: [206071.175603] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 12:57:44 ядро ubuntu: [206071.618695] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 12:57:44 ядро ubuntu: [206072.062224] usb 1-1.2: сброс высокоскоростного USB-устройства номер 23 с помощью ehci_hcd 12 июня 12:57:44 ядро ubuntu: [206072.095010] usb 1-1.2: USB отключен, номер устройства 23 12 июня 12:57:44 ядро ubuntu: [206072.098317] scsi 16:0:0:0: отклонение ввода-вывода на автономное устройство 12 июня 12:57:44 ядро ubuntu: [206072.098327] scsi 16:0:0:0: [sdb] запрос на уничтожение 12 июня 12:57:44 ядро ubuntu: [206072.098345] scsi 16:0:0:0: [sdb] Необработанный код ошибки 12 июня 12:57:44 ядро ubuntu: [206072.098349] scsi 16:0:0:0: [sdb] Результат: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK 12 июня 12:57:44 ядро ubuntu: [206072.098356] scsi 16:0:0:0: [sdb] CDB: Чтение(10): 28 00 03 66 90 8b 00 00 01 00 12 июня 12:57:44 ядро ubuntu: [206072.098387] end_request: ошибка ввода-вывода, dev sdb, сектор 57053323 12 июня 12:57:44 ядро ubuntu: [206072.309890] usb 1-1.2: новое высокоскоростное USB-устройство номер 26 с использованием ehci_hcd 12 июня 12:57:45 ubuntu mtp-probe: проверка шины 1, устройство 26: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2" 12 июня 12:57:45 ubuntu mtp-probe: шина: 1, устройство: 26 не является устройством MTP 12 июня 12:57:45 ядро ubuntu: [206072.755377] scsi17 : usb-storage 1-1.2:1.0 12 июня 12:57:46 ядро ubuntu: [206074.240443] scsi 17:0:0:0: Прямой доступ HTS72101 0G9SA00 PQ: 0 ANSI: 6 12 июня 12:57:46 ядро ubuntu: [206074.242675] sd 17:0:0:0: Прикрепленный scsi generic sg2 type 0 12 июня 12:57:46 ядро ubuntu: [206074.243800] sd 17:0:0:0: [sdc] 195371568 512-байтовые логические блоки: (100 ГБ/93,1 ГиБ)
Проблема там начинается с отключения USB вместо сброса. Это проблема, которую мне нужно избежать.
Я хотел бы как-то заставить его оставаться включенным /dev/sdb. Есть ли способ сделать это?
В качестве альтернативы, хотя кажется, что этот тип жесткого сброса неизбежен, есть ли где-то какие-то настройки, которые я могу временно изменить, чтобы, возможно, предотвратить это? Какой-то таймер повтора или что-то в этом роде? Или, может быть, способ заставить /dev/sdbснова стать доступным сразу, чтобы его можно было использовать повторно?
Приложение, которое я сейчас запускаю, открывает устройство один раз при запуске и держит его открытым все время, пытаясь восстановиться. Я написал это приложение и могу управлять его поведением, поэтому решение в коде также возможно, но я хотел бы сначала посмотреть, есть ли решение на системном уровне (я пока не пробовал обходной путь с помощью программного обеспечения, я хочу посмотреть, есть ли более простой способ).
Мне также интересно, может ли это быть проблема с питанием, хотя я не вижу никаких проблем, связанных с питанием, в журнале. Я пока не пробовал концентратор с питанием. Машина — Lenovo ThinkPad T520 (работает от сети переменного тока), которая никогда не подводила меня с точки зрения доступного тока USB в прошлом.
Система — Ubuntu 12.04 LTS, ядро 3.2.0-64, 64-бит.
решение1
Доступ к устройству осуществляется через пути /dev/disk/by-xxx.
Эти пути остаются теми же для устройства/раздела, с символическими ссылками на само устройство /dev/sdXY, поддерживаемыми системой. Таким образом, хотя устройство может переподключаться к другомувиртуальныйустройство, путь, который вы можете использовать, не изменится.
/dev/disk/by-uuid/
Каждый диск/устройство имеет уникальный UUID, поэтому использование пути на его основе всегда одинаково, независимо от того, к какому «устройству» он ведет. Например, моя система:
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Путь
/dev/disk/by-uuid/b2254550-cc90-46e4-a84f-cb32bca8f83dвсегда будет указывать на раздел 1 этого диска, независимо от того, является ли он sda/sdb/sdc и т. д.
Существуют и другие доступные методы:
/dev/disk/по-метке/
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
Я всегда маркирую свои разделы, что значительно упрощает процесс хранения/использования/монтирования конкретного устройства, а не заставляет задуматься, является ли /dev/sdc диском WD на 1 ТБ, или Samsung на 2 ТБ, или флешкой на 1 ГБ.
Также облегчает монтаж: (из/etc/fstab)
LABEL=xenon / ext4 defaults,... and so forth
Theобходной путьpath может быть полезен, поскольку он технически связывает физическое подключение с определенным устройством, что может быть полезно, если диск плохо работает с правильной информацией о разделах, выдавая странные метки или что-то в этом роде.