2

I have a hard drive in a USB enclosure that I am doing some data recovery on. The drive is in extremely bad shape and frequently resets on reads.

The device registers as /dev/sdb. Sometimes, probably about once in every few thousand resets, for some reason it switches over to /dev/sdc. The only way to get it to go back is to physically unplug the USB connection for a few seconds then reattach, at which point it registers as /dev/sdb again.

This is very disruptive and causing a lot of issues for me, as some of the operations I'm performing can take hours or days, and if this happens at any point in that process (e.g. while I am at work or asleep) I either have to try to determine when it happened and resume from that point, or start over. Both are very difficult.

A "normal" set of resets, which I expect and are OK, look like this:

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

This is the expected behavior. A problematic reset, which switches over to sdc, looks like this:

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)

The issue there starts with a USB disconnect instead of a reset. That is the problem I need to avoid.

I would like to force it somehow to stay on /dev/sdb. Is there any way I can do this?

Alternatively, while it seems like this type of hard reset is unavoidable, is there some setting somewhere I can temporarily change to perhaps prevent this from happening? Some retry timer or something? Or maybe a way to force /dev/sdb to become available again right away so that it is reused?

The application I am currently running opens the device once on start and holds it open the entire time while attempting recovery. I wrote this application and can control its behavior, so a solution in code is also a possibility but I'd like to see if there is a system-level solution first (I have not attempted a software workaround yet, I want to see if there is an easier way).

I also wonder if it is perhaps a power problem although I see no power-related issues in the log. I have not tried a powered hub yet. The machine is a Lenovo ThinkPad T520 (running on AC power) which has never failed me in terms of available USB current in the past.

System is Ubuntu 12.04 LTS, kernel 3.2.0-64, 64-bit.

Improve this question

1 Answer 1

Reset to default
6

Access the device through the /dev/disk/by-xxx paths.

These paths remain the same for the device/partition, with symlinks to the proper /dev/sdXY device itself, maintained by the system. So while the device might reconnect to another virtual device, the path you can use doesn't change.

/dev/disk/by-uuid/

  • Every drive/device has a unique UUID, so using a path based on that is always the same, regardless of which 'device' it leads to. For instance, my system:

    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

  • The path /dev/disk/by-uuid/b2254550-cc90-46e4-a84f-cb32bca8f83d will always point to partition 1 of that drive, regardless of whether it's sda/sdb/sdc, etc.

There are other methods available too:

/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

I always label my partitions, makes it super simple to file/use/mount a particular unit, rather than wondering if /dev/sdc is the WD 1TB, or the Samsung 2TB, or the 1GB flash drive.

Also makes mounting easier: (from /etc/fstab)

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

The by-path path can be useful since it technically associates a physical connection to a particular device, perhaps useful for you if the drive doesn't play well with proper partition info, giving odd labels or such.

Improve this answer
3
  • Thanks! This is useful in general although I might have been unclear in my question. The problem for me is that the device disconnects and changes while the application is running. I might be going about this the wrong way, too; maybe what I really need is a way to keep it from resetting -- /dev/sdb or not, thinking about it the reset probably ruins the file handles anyways. What I'm going to try is accessing it like you say here, and then perhaps I can detect the disconnect via error codes in software, but then I can just reopen the device using a /dev/disk path so I don't have to guess.
    – Jason C
    Commented Jun 12, 2014 at 20:52
  • ^ If I can get that working I'll mark this as the solution, even though it's not a direct answer it is really helpful and gives me some ideas.
    – Jason C
    Commented Jun 12, 2014 at 20:52
  • 1
    It occurred to me that if you're not occasionally re-opening the device it might get confusing. But if an error occurs, closing and reopening the device using the same path should get you back on track, and like you said, no guessing what the device name is. If the drive is corrupt, behavior is undefined, best of luck.
    – lornix
    Commented Jun 12, 2014 at 21:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .