Partition Table Not Recognized in USB -C Enclosure

[larryr]

Per that #15

Old usb sees sector size as 512 usb-c reports sector size as 4096.

so mapping drive info is incompatible as each pointer on the disk is somewhere else depending on the USB to SATA handshake.

Unlike real SATA on a motherboard - you are talking USB to a SATA disk - the translations can be different depending on whose USB to SATA chip is used and whether the USB is seen as uas or usb-storage to udev. (to see you use lsusb -t)

My explanation of what happens is : I measure everything in kilometers and you decide to switch to miles but don't change the distances - I tell you to go 300 kilometers and you go 300 miles - you are not in the same spot that I told you to go - that is what the disk is doing wrong measurement.

[idanan]

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).

Hi,

Thank for trying to clear things up. Personally, I am confused because this issue is rather bizarre which may have confused others too.

Right, a partition table is just data with a known location (and size I believe). That partition table (and the actual single partition following it) can be read with the drive in the USB 3.0 enclosure,

So, what could the USB-C enclosure being doing that prevents the operating system from recognizing the partition table? parted outputs Partition Table: unknown

This could come down to expectations from the operating system due to the different geometry reported. Where is the partition table exactly? If it's placement and size is defined by the block
size, then there would be an issue since. It could also be the case if the USB 3.0 and USB-C enclosure disagree on where the start of the disk is, which again seems rather strange but don't
any better guesses.

In the working USB 3.0 enclosure:

Nov 25 16:23:11 vega kernel: sd 11:0:0:0: [sdj] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
In the USB-C enclosure:

Nov 25 16:27:45 vega kernel: sd 11:0:0:0: [sdj] 976754646 4096-byte logical blocks: (4.00 TB/3.64 TiB)
Again, same disk, shows the same size but in one it is presented as made of 512-byte blocks and the other as 4096-byte blocks.
Beyond reading the actual data, this could have performance implications. If the block size is incorrectly reported by the enclosure
(which could even be the working 3.0 enclosure just because that's where the drive was formatted), then it could be inefficient I/O
and cause excessive wear on the disk.

Is there a way to know the block size of the disk? I'll check on the manufacturers's (SanDisk) website in case they have it listed.

Thanks again!

[idanan]

Per that #15
My explanation of what happens is : I measure everything in kilometers and you decide to switch to miles but don't change the distances - I tell you to go 300 kilometers and you go 300 miles - you are not in the same spot that I told you to go - that is what the disk is doing wrong measurement.

Great analogy! That implies that the different USB bridges are exposing a different representation for the same disk and the operating system is using the units exposed by the enclosure to determine where the partition table is and possibly how to interpret its content.

That is really worrisome but it makes sense.... so had I formatted the drive in the USB-C enclosure, I would not have been able to read it in the USB 3.0 one, right?

This would also explain a completely unrelated incident that occurred with a different disk and enclosure. Previously I had another SATA disk inside a completely different enclosure which as USB 2.0 port and an eSATA port. This was my old backup drive which regularly refreshed via eSATA. When I tried to restore this backup onto a new system that did not have an eSATA port, I plugged it in via USB 2.0 and it appeared completely empty. Again, no partition, nothing. I thought the disk died and luckily this was a secondary backup, so I got all my files from a network backup.

All pieces of this puzzle seem to fit now

Thank you!

[larryr]

That is really worrisome but it makes sense.... so had I formatted the drive in the USB-C enclosure, I would not have been able to read it in the USB 3.0 one, right?

Thats right. It seems that the "starting sector" might be 0 or 1 on different chips and the size of the USB buffer sets the sector size - 512, 1024, 2018 and 4096 - I have seen every one on different brands of USB to SATA controllers - Even Seagate will be different for the "Same" model but different manufacture dates.

[karlmistelberger]

That is really worrisome but it makes sense.... so had I formatted the drive in the USB-C enclosure, I would not have been able to read it in the USB 3.0 one, right?

Attach the disk directly to the main board using a SATA cable and format it. Should look similar to this one, 4k physical sectors, large size limit:

erlangen:~ # fdisk -l /dev/sda 
Disk /dev/sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRX-22S 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 4096 bytes 
I/O size (minimum/optimal): 4096 bytes / 4096 bytes 
Disklabel type: gpt 
Disk identifier: 27C8C52A-8091-403C-ADF1-E9C791667D40 

Device     Start       End   Sectors SizeType
/dev/sda1    67119104  134223871   67104768   32G Linux filesystem 
/dev/sda2       16384   67119103   67102720   32G Linux filesystem 
/dev/sda3  7757789184 7814037134   56247951 26.8G Linux filesystem 
/dev/sda4   134223872 7757789183 7623565312  3.6T Linux filesystem 

Partition table entries are not in disk order. 
erlangen:~ #

Only then try the adapter and see whether it works. If it doesn't buy a compatible one.

Small disk, small sectors, size limit 2TiB:

erlangen:~ # fdisk -l /dev/sdd 
Disk /dev/sdd: 1.84 TiB, 2000365289472 bytes, 3906963456 sectors
Disk model: Elements 1078    
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier: 0x73a16023 

DeviceBootStart       End   Sectors SizeIdType
/dev/sdd1        2048 3906963455 3906961408  1.8T 83 Linux 
erlangen:~ #