Partition Table Not Recognized in USB -C Enclosure

English Hardware
1

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:

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:

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:

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:

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
2

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.

3

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

4

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

5

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

6

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.

7

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

8

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.

9

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

**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!

10

Disk is back in case:

**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:~ #**
11

The sector size thing the manufacturer described is new to me.
Only thing I’d heard of before that’s even close but I doubt is the case is the INT BIOS 13 issue… On older BIOS, you have to store your disk initialization files near the beginning of your disk because the BIOS can’t read the entire disk initially… After the disk is mounted, the entire disk can be seen.

TSU

12

[FONT=monospace]**

**Nov 25 13:14:10 erlangen kernel: **sd 6:0:0:0: [sda] 4294967296 512-byte logical blocks: (2.20 TB/2.00 TiB)**[/FONT]**[FONT=monospace]**

**
It is an example of no drive larger than 2 tb - the chip for SATA to USB has the 2TB limit.
**[/FONT]

13

Interesting. Until recently I never noticed any compatibility issues. Modern drives are more complex than I thought!

Strangely, as mentioned in the original post, my 4TB drives work in a USB 3.0 enclosure but not in a a USB-C one!
I have two 4TB disks and they work in two different USB 3.0 enclosures but neither work in a USB-C one. I even tried
a second sample of the USB-C enclosure, in case it was defective. Manufacturer says it could work if I reformat the
drive. There’s over 2TB of data in there, so it’s going to be very cumbersome to back it up to try to repartition the
media.

14

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

that device will only support up to 2 TB - what I said many responses ago - It reports as a 2 TB drive - That is the max the chip in that adapter can support.

15

Hi,

OK, it looks like journalctl is more useful in debugging, so here is the output using the working USB 3.0 enclosure:

Nov 25 16:23:11 vega kernel: scsi 11:0:0:0: Direct-Access     SanDisk  SDSSDH3 4T00     4110 PQ: 0 ANSI: 6
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: Attached scsi generic sg10 type 0
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] Write Protect is off
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] Mode Sense: 2f 00 00 00
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] Optimal transfer size 33553920 bytes
Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] Attached SCSI disk

Now, moving the disk into the USB 3.1 enclosure, it shows:

Nov 25 16:27:45 vega kernel: scsi 11:0:0:0: Direct-Access     SanDisk  SDSSDH3 4T00     3101 PQ: 0 ANSI: 6
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: Attached scsi generic sg10 type 0
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] 976754646 4096-byte logical blocks: (4.00 TB/3.64 TiB)
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] Write Protect is off
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] Mode Sense: 53 00 00 08
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] Optimal transfer size 33550336 bytes
Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] Attached SCSI disk

The information on the disk and size matches which means it at least recognizes 4TB but for some reason it appears
as unpartitioned even though there is data on the drive.

What does the Mode Sense line mean? It’s completely different ‘Mode Sense: 2f 00 00 00’ while working in USB 3.0
and ‘Mode Sense: 53 00 00 08’ while not working in USB-C enclosure.

Is there a way to correct the partition table or something in the driver so that the drive understood by the new enclosure?
Hopefully others too… I wouldn’t want to lose access to the data if the enclosure breaks and needs to be changed just
because the next one is not exactly the same!

Thanks,

  • Itai
16

In my opinion you are asking for trouble. I recommend you buy a new adapter which supports larger disks without further tinkering.

17

From this and other posts you made I am getting the impression that you have a slight misunderstanding about the concept of what a partition table is. And this hampers the understanding between you and the others.

You seem to think that a partition table is something very special that stands off from the data space on the disk. This is not the case. The partition table is also data. If there is a partition table (and I believe you when you say there is) it is just data as all other data. To the hardware/firmware it is just bytes like all other bytes on the disk. The only thing is that they are on the very start of the disk, but when there is no partition table, there will be something different on the start of the disk.

That data on the start of the disk will only be interpreted as a partition table by the operating system (and NOT by the hardware/firmware) as it looks like a partition table. But that is all done way after the hardware is detected, maker/type identified, a driver connected, etc.

Thus, when for some reason, no data can be read from the disk, the partition table will also not be found. While the showing of partitions in e.g. /dev/disk/ definitely points to the fact that the begin of the disk can be read, being unable to read will result in no detection of any partition table.

Thus, as said by others, it seems that reading from that disk inside the enclosure is impossible. (the first sign of that unreadability of the disk will of course result in no partition table detected).

18

Look at response 14

journalctl clearly show the USB-C device saying the drive is 2 TB not 4 TB.

19

**Response #14 is not mine (OP) **but I did run the same test in response 15 and we can clearly see that both disks are shown as (4.00 TB/3.64 TiB).

The difference though is in the block-size which is puzzling to me because this is *the same physical disk *which I have been removing from one
enclosure and putting into the other.

Why is the block size different for the same drive in 2 enclosures? It is not a property of the disk?

The drive is readable and presumably writable (since it says Write Protect is off regardless of enclosure) but I don’t want to disk writing to the
disk when it’s partition cannot be recognized but raw data can be read via dd, unless it just returns garbage. Maybe I’ll try a different test later
by reading the same offset using each enclosure and comparing.

Does that help clear up the situation?

Thanks

20

Because you are seeing the logical block size, not the physical block size. The controller in the USB enclosure is doing block translation. See this article USB adapters silently change the sector size for a brief explanation.