Ubuntu 11.04 and large external drives

Question

I have a Hitachi USB external 3 terabyte drive attached to a Dell Precision T1500. When connected to the computer running Ubuntu 11.04 (2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux) the following appears in the logs:

[1636365.665558] usb 2-1.7: new high speed USB device using ehci_hcd and address 15 
[1636365.813198] scsi18 : uas 
[1636377.895182] scsi 18:0:0:0: Direct-Access     Hitachi  Hitachi HDS72303 A580 PQ: 0 ANSI: 4 
[1636384.388480] scsi 18:0:0:0: uas_eh_abort_handler tag 0 
[1636384.388485] scsi 18:0:0:0: uas_eh_device_reset_handler tag 0 
[1636384.388487] scsi 18:0:0:0: uas_eh_target_reset_handler tag 0 
[1636384.388489] scsi 18:0:0:0: uas_eh_bus_reset_handler tag 0 
[1636384.468415] usb 2-1.7: reset high speed USB device using ehci_hcd and address 15 
[1636384.609589] scsi 18:0:0:0: Device offlined - not ready after error recovery 
[1636384.609649] scsi 18:0:0:0: rejecting I/O to offline device 
[1636384.609663] scsi 18:0:0:0: rejecting I/O to offline device 
[1636384.610978] scsi 18:0:0:1: Enclosure         Hitachi  SES              A580 PQ: 0 ANSI: 4 
[1636384.611472] scsi 18:0:0:2: uas_eh_device_reset_handler tag -1 
[1636384.611477] scsi 18:0:0:2: uas_eh_target_reset_handler tag -1 
[1636384.611481] scsi 18:0:0:2: uas_eh_bus_reset_handler tag -1 
[1636384.707808] usb 2-1.7: reset high speed USB device using ehci_hcd and address 15 
[1636384.838735] scsi 18:0:0:2: Device offlined - not ready after error recovery 
[1636384.838952] sd 18:0:0:0: Attached scsi generic sg4 type 0 
[1636384.839029] ses 18:0:0:1: Attached Enclosure device 
[1636384.839080] ses 18:0:0:1: Attached scsi generic sg5 type 13 [1636415.301027] sd 18:0:0:0: uas_eh_abort_handler tag 0 
[1636415.301036] sd 18:0:0:0: uas_eh_device_reset_handler tag 0 
[1636415.301042] sd 18:0:0:0: uas_eh_target_reset_handler tag 0 
[1636415.301046] sd 18:0:0:0: uas_eh_bus_reset_handler tag 0 
[1636415.381053] usb 2-1.7: reset high speed USB device using ehci_hcd and address 15 
[1636415.522005] sd 18:0:0:0: Device offlined - not ready after error recovery 
[1636415.522080] sd 18:0:0:0: rejecting I/O to offline device 
[1636415.522093] sd 18:0:0:0: rejecting I/O to offline device 
[1636415.522101] sd 18:0:0:0: rejecting I/O to offline device 
[1636415.522107] sd 18:0:0:0: [sdc] READ CAPACITY failed 
[1636415.522110] sd 18:0:0:0: [sdc]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK 
[1636415.522116] sd 18:0:0:0: [sdc] Sense not available. 
[1636415.522123] sd 18:0:0:0: rejecting I/O to offline device 
[1636415.522129] sd 18:0:0:0: [sdc] Write Protect is off 
[1636415.522133] sd 18:0:0:0: [sdc] Mode Sense: 00 00 00 00 
[1636415.522139] sd 18:0:0:0: rejecting I/O to offline device 
[1636415.522144] sd 18:0:0:0: [sdc] Asking for cache data failed 
[1636415.522147] sd 18:0:0:0: [sdc] Assuming drive cache: write through 
[1636415.522355] sd 18:0:0:0: [sdc] Attached SCSI disk

From what I've found in the Internet it may be tied to having a partition larger than 2 TB. I connected the drive to an Windows XP system and split the drive into two NTFS partitions, 1.5 TB each. It currently has a GUID partition table.

I've tried using gdisk to see the drive but Linux isn't acknowledging that the drive is in any way usable. It seems to work under Windows and OS X, though (or at least it's seen by the utilities for formatting and partitioning under those OS's...)

Am I missing something simple here to get it to work properly under Linux?

Answer 1

There are several possible causes and things that you might do. The dmesg excerpt suggests a few things:

• The kernel tries several times to access the device. It seems that each time it does not finish for some reason.
• There are notices saying not ready after error recovery which indicate that the drive either failed to undergo filesystem checks (although those were attempted) or needs to be checked but your system does not know how to do that.
• The drive is accessed using the new uas kernel driver - it is probably the only way in case of drives >2TB, but worth knowing when you search for solutions.

Possible causes I can think of:

• The drive electronics shipped with the enclosure is set to use non-standard-compliant communication settings or device powering. If powering were the problem and your enclosure came with an external power supply, you should definitely use it if you didn't so far. In case the problem were with some proprietary communication mechanisms, you might solve it by going through the enclosure manual or running a Windows program that can switch the drive to standard or legacy mode (it may be called just anything).

• The drive takes too long to settle - your system might be configured to wait too short before the drive makes itself available after plugging in. To check/change this, do cat /sys/module/usb_storage/parameters/delay_use - you will see a value in seconds. If it is 5 seconds or less, try changing it to, say, 10 (sudo echo 10 > sys/module/usb_storage/parameters/delay_use) and then plug the drive in.

• Kernel does not know GPT partition type. You say you used gdisk, but it may not have been able to recognize GPT partitions because those were simply not known to the kernel. To check this, verify that your current kernel configuration has both CONFIG_PARTITION_ADVANCED and CONFIG_EFI set to y (from what I recall, on Ubuntu the kernel configs reside under /boot directory).

• Since you used NTFS (not a good fs for large drives in my opinion, but then - there is no good alternative to work with Windows either), the filesystem might need to undergo a consistency check. This might prevent linux tools from mounting it, but would not explain why the drive isn't correctly recognized by gdisk. Nevertheless, plugging it into a Windows machine an doing a full checkdisk won't hurt.

• Having skimmed through this forum thread I believe that the main problem could be the drive enclosure after all.