1

I've bought a new 4TB hard drive, a Western Digital WD40PURX, to replace an existing 1TB drive, and because I don't have a free internal SATA port - I've used a USB-to-SATA adapter I had lying around to connect the drive temporarily so I can move the data over - before switching the drives.

But when I'm trying to partition the drive, Ubuntu only sees 1.6 TB of size:

# gdisk -l /dev/sdg
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk /dev/sdg: 3519069872 sectors, 1.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): B19A7DC5-52A5-44AD-B295-51C8853A9EBB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3519069838
Partitions will be aligned on 2048-sector boundaries
Total free space is 3519069805 sectors (1.6 TiB)

And here's smartctl:

# smartctl -x /dev/sdg 
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-49-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Purple
Device Model:     WDC WD40PURX-64GVNY0
Serial Number:    WD-WCC4E3YY1VKE
LU WWN Device Id: 5 0014ee 2b849189a
Firmware Version: 80.00A80
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Wed Apr 26 11:23:10 2017 IDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Write SCT (Get) Feature Control Command failed: Read of ATA output registers not implemented [JMicron]
Wt Cache Reorder: Unknown (SCT Feature Control command failed)

Here's lsusb:

# lsusb | grep SATA
Bus 001 Device 002: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. 
  JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

I've search around for something like a size limit for USB mass storage devices, but that doesn't seem to be the case.

[Update]: After looking at the discussions pointed to by @Mitch, I've tried setting the drive to "Advanced Format" using a jumper, without success - after setting the jumper, the drive still identifies as "Sector size: 512 bytes logical, 4096 bytes physical".

I'd appreciate any thoughts on the subject.

4
  • Have you tried a different adapter? See Here.
    – Mitch
    Apr 26, 2017 at 8:55
  • Unfortunately, I don't have one available. Also, the problem described in your link is somewhat different than mine - as I understand it, gdisk reported 4TB available on the OPs system, which is not the case on my system.
    – Guss
    Apr 26, 2017 at 9:16
  • Why not reverse the operation? Install the new 4TB in the computer and stick the 1TB on the USB adapter? Most linuxes will still boot and work in that fashion (albeit a bit slowly), as long as the BIOS is forced to boot from the USB.
    – sergtech
    Apr 27, 2017 at 8:23
  • @sergtech-S.Dragomir - its not the main drive. The drive to be replaced is part of a BTRFS array. But that sounds very doable - I'll try that. Mind writing it up as an answer?
    – Guss
    Apr 27, 2017 at 8:25

2 Answers 2

1

A possible solution to the problem would be to directly attach the larger 4TB drive to the computer SATA port and the smaller drive on the usb adapter.

Most new Linux Systems could run directly off the USB, as long as the BIOS would be forced to boot off USB (although a bit slowly).

An indirect solution could follow from here or here. It seems other people are having similar problems due to this specific JMicron adapter, whose quirks were fixed but then re-appeared. Maybe try running a different kernel where the bug hadn't re-occurred.

1
  • I didn't try the quirks mode, but I got a new adapter and that works fine. I'll try to mess with it when I finish migrating and have a spare 2TB drive to play with :-)
    – Guss
    Apr 27, 2017 at 21:09
1

JM20337 is somewhat cursed.

Putting aside every enclosure is different and you never know (there seems to be more board revisions, and the data corruption bug observed here, was not found elsewhere), while it should support LBA48 addressing it seems to have a bug with the reported block length size (for reasons it's only to be hit on >2TB disks)

This should have been fixed years ago, but as reported at the end of a link in the other answer, maybe there's something else to consider, or maybe there was a regression. Windows has a slightly different detection logic, so it may (not?) work there.

EDIT: scratch that. Although "so new" that it even supported some SATA 2 feature, it seems like in 2004 they had still been skimping on implementing 48-bit commands on the USB side of the bridge. And there's no firmware update whatsoever that I could find. Though I wonder if this couldn't still be workaroundable (say, you try to stick in "4096-blocks" mode, skip the clipped disk size reports and attempt some way else to find it).

EDIT2: seems like at least older JMicron controllers like this didn't have all the SCSI/ATA Translation command blocks in the expected order and format.. I guess understandably since when they shipped, the corresponding working group had just barely formed (other bridge manufacturers had even proprietary protocols). So perhaps the big deal to overcome is just here?

You must log in to answer this question.

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