Partition Table Not Recognized in USB -C Enclosure

**idanan** · 24-Nov-2020, 15:04

Hi,

This is a strange one and I don't know where to even start. There is a 4TB SSD used to share data between various operating systems.
It's been a USB 3.0 enclosure for a while and works completely fine in there with its original USB 3.0 cable or with an A-to-C cable.

Now, when the same physical disk is placed inside a native USB-C enclosure, the disk itself is recognized but not its partition! Nothing
bad happened to the disk and placing it back into the USB 3.0 enclosure shows the partition again.

Here is the output of fdisk with the drive mounted in the USB 3.0 enclosure:

Code:

sudo fdisk -l /dev/sdj
Disk /dev/sdj: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: SDSSDH3 4T00    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 14ECEFB8-26F5-4334-B8ED-23714983E185


Device     Start        End    Sectors  Size Type
/dev/sdj1   2048 7814037134 7814035087  3.7T Microsoft basic data

Here is the output of parted with the drive mounted in the USB 3.0 enclosure:

Code:

Model: SanDisk SDSSDH3 4T00 (scsi)
Disk /dev/sdj: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 


Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  4001GB  4001GB  fat32        Microsoft basic data  msftdata

Now, the same disk inside the USB-C enclosure shows different output from fdisk:

Code:

sudo fdisk -l /dev/sdj
Disk /dev/sdj: 3.7 TiB, 4000787030016 bytes, 976754646 sectors
Disk model: SDSSDH3 4T00    
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
Disklabel type: dos
Disk identifier: 0x00000000


Device     Boot Start        End    Sectors Size Id Type
/dev/sdj1           1 4294967295 4294967295  16T ee GPT

It also shows a different output for parted:

Code:

Error: /dev/sdj: unrecognised disk label
Model: SanDisk SDSSDH3 4T00 (scsi)                                        
Disk /dev/sdj: 4001GB
Sector size (logical/physical): 4096B/4096B
Partition Table: unknown
Disk Flags:

Note that below 'Disk Flags' there is just a blank line on the output when in the USB-C enclosure but it shows a partition in the USB 3.0 enclosure.

Any idea what is happening and if there is a way to make its partition visible from the USB-C enclosure? The drive is very fast, so it could work a
little faster in USB-C if I can get it to see the data!

Thank you,

- Itai

**larryr** · 24-Nov-2020, 15:35

Many USB C enclosure only support 2TB drives. I wonder if that is the issue.

Is it a 2.5" SSD drive or an m.2 unit. I have yet to find an m.2 that supports more than 2TB.

I have a few usb 3 to 2.5 cables that work fine with 4tb SSD drives.

**tsu2** · 24-Nov-2020, 15:52

Hi,
Pls post results from using the same tools each time it's mounted differently.
If you use different tools each time you mount differently, the results can't be compared.
Consistency is important.

BTW -
Early suspicion is that your disk is a SATA disk, and mounting internally might involve a SCSI to SATA bridge. It shouldn't make a difference, but hardware bridging devices can be weird. I use a USB to SATA bridge (It's not a straight USB to SATA connection) which causes weird issues from time to time but not an outright unable to identify disk partitions for most uses.

TSU

**idanan** · 24-Nov-2020, 16:26

Originally Posted by larryr

Many USB C enclosure only support 2TB drives. I wonder if that is the issue.

Is it a 2.5" SSD drive or an m.2 unit. I have yet to find an m.2 that supports more than 2TB.

I have a few usb 3 to 2.5 cables that work fine with 4tb SSD drives.

It is a 2.5" SSD. Interesting but wouldn't it not _see_ the disk at all if it was unsupported?

Sorry, what do you mean by usb 3 to 2.5 cables? Do you mean USB C-to-A cable?

Thanks

**idanan** · 24-Nov-2020, 16:31

Originally Posted by tsu2

Hi,
Pls post results from using the same tools each time it's mounted differently.
If you use different tools each time you mount differently, the results can't be compared.
Consistency is important.

BTW -
Early suspicion is that your disk is a SATA disk, and mounting internally might involve a SCSI to SATA bridge. It shouldn't make a difference, but hardware bridging devices can be weird. I use a USB to SATA bridge (It's not a straight USB to SATA connection) which causes weird issues from time to time but not an outright unable to identify disk partitions for most uses.

TSU

Hi,

Well, I wasn't sure which tool would give the most relevant info, so I used BOTH tools on BOTH enclosures. First fdisk than parted on the USB 3.0 enclosure, then again both fdisk
and parted on the USB-C enclosure. Same disk is used and both times mounted external just in a different enclosure. I am out of SATA ports, so I didn't mount it internally but since
it works via the USB 3.0 enclosure, the drive is probably fine. It is less than a year old and never gave any trouble in its USB 3.0 enclosure.

Given that the drive is detected with the correct size with the USB-C enclosure, could it be a software bug with the USB-C drivers? Or would a hardware issue in the enclosure itself
cause such a strange bug?

Thanks

**larryr** · 24-Nov-2020, 17:05

Originally Posted by idanan

It is a 2.5" SSD. Interesting but wouldn't it not _see_ the disk at all if it was unsupported?

Sorry, what do you mean by usb 3 to 2.5 cables? Do you mean USB C-to-A cable?

Thanks

Have not found any usb C (or 3.1) that works right with larger than 2TB drive.

My USB 3.0 to SATA 2.5" cables work fine with up to 8TB. (those are blue cables ends but stuck at 480 transfer not the 5000 or 10000 that my laptop supports.)

I get weird results with every USB 3.1 (or C) devices when larger than 2 TB - they sometimes see the correct size but data is garbage when read.

I suspect you want a 5000 to 10000 transfer rate when you do a lsusb -t.

**idanan** · 24-Nov-2020, 18:16

Hi,

The manufacturer got back to me fairly quickly regarding the issue. They say:

This can happen if the drive when in the other USB 3.0 enclosure was prep using different sector size. When it is move to our enclosure, the OS cannot read it.

We have tested this up to 8TB (Samsung QVO 870 - 8TB SSD) and there are new bigger capacity drives out every month and we will continue to update our specs for bigger capacity drives.

Is there any way to validate this? What sector size are they referring to? Since this affects the partition table, it should be matter the file-system and so doesn't the hardware
dictate the sector size?

Thanks

**larryr** · 24-Nov-2020, 19:21

The SATA to USB chip does a device configuration string that is sent when udev sees a new USB device. It does not send the real head/cylinder/sector from the drive but what the buffer for the device works best with - the total number of sectors should be close - some controllers keep a different number of sectors to map bad spots to. This is to make the device more reliable for bad power off and sectors damage while the power dropped while being written. This has been the norm since USB 2 was defined in 1998. Every USB to SATA chip seems to do it differently - some better than others.

I can see how the windows format program could write in areas different than where the Linux NTFS or FAT32 program gets its data from udev. Windows uses one formula for the allocation maps and Linux may align sectors on performance sector/head/track numbers that do not match what Windows chose. If the controller from Vendor 1 aligns in track boundaries and Vendor 2 aligns by sector boundaries - the data will be look like what you see.

If you are using NTFS or FAT32 - you best bet at compatibility is to allow Windows 10 to format the drive for use on both Windows and Linux. I have had an issue with an NTFS drive formatted back with OpenSUSE 42.1 that Windows 7 had issues with - but worked fine when Windows 7 formatted the drive NTFS.

**karlmistelberger** · 25-Nov-2020, 05:24

Originally Posted by idanan

It is a 2.5" SSD. Interesting but wouldn't it not _see_ the disk at all if it was unsupported?

Sorry, what do you mean by usb 3 to 2.5 cables? Do you mean USB C-to-A cable?

Thanks

Removed a 4 TB disk from the case and attached it via USB:

Code:

erlangen:~ # journalctl -b 0 _KERNEL_SUBSYSTEM=scsi --since 13:14:04 
-- Logs begin at Sat 2020-11-14 06:05:06 CET, end at Wed 2020-11-25 13:20:10 CET. -- 
Nov 25 13:14:04 erlangen kernel: sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK 
Nov 25 13:14:04 erlangen kernel: sd 6:0:0:0: [sda] Sense not available.
Nov 25 13:14:04 erlangen kernel: sd 6:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
Nov 25 13:14:04 erlangen kernel: sd 6:0:0:0: [sda] Attached SCSI disk
Nov 25 13:14:09 erlangen kernel: scsi host6: usb-storage 2-6:1.0 
Nov 25 13:14:10 erlangen kernel: scsi host6: scsi scan: INQUIRY result too short (5), using 36 
Nov 25 13:14:10 erlangen kernel: scsi 6:0:0:0: Direct-Access     WDC WD40 EZRX-22SPEB0          PQ: 0 ANSI: 0
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: Attached scsi generic sg0 type 0
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] 4294967296 512-byte logical blocks: (2.20 TB/2.00 TiB)
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] Write Protect is off
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] Mode Sense: 3b 00 00 00
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] No Caching mode page found
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] Assuming drive cache: write through
Nov 25 13:14:10 erlangen kernel: sd 6:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
Nov 25 13:17:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 timing out command, waited 180s
Nov 25 13:17:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=180s 
Nov 25 13:17:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 Sense Key : Hardware Error [current]  
Nov 25 13:17:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 Add. Sense: Logical unit communication CRC error (Ultra-DMA/32) 
Nov 25 13:17:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 
Nov 25 13:20:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 timing out command, waited 180s
Nov 25 13:20:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=180s 
Nov 25 13:20:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 Sense Key : Hardware Error [current]  
Nov 25 13:20:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 Add. Sense: Logical unit communication CRC error (Ultra-DMA/32) 
Nov 25 13:20:10 erlangen kernel: sd 6:0:0:0: [sda] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 01 00 00 00 07 00 00 
erlangen:~ #

Short answer: It doesn't work!

**karlmistelberger** · 25-Nov-2020, 05:33

Disk is back in case:

Code:

erlangen:~ # journalctl -b 0 _KERNEL_SUBSYSTEM=scsi --since 13:26:13 
-- Logs begin at Sat 2020-11-14 06:05:06 CET, end at Wed 2020-11-25 13:31:30 CET. -- 
Nov 25 13:26:13 erlangen kernel: scsi 2:0:0:0: Direct-Access     ATA      WDC WD40EZRX-22S 0A80 PQ: 0 ANSI: 5
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] 4096-byte physical blocks
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] Write Protect is off
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Nov 25 13:26:13 erlangen kernel: sd 2:0:0:0: [sda] Attached SCSI disk
erlangen:~ #