Page 3 of 3 FirstFirst 123
Results 21 to 25 of 25

Thread: Partition Table Not Recognized in USB -C Enclosure

  1. #21
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    406

    Default Re: Partition Table Not Recognized in USB -C Enclosure

    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.
    OpenSUSE 15.2 with VirtualBox VM's (XP, 10, Ubuntu MATE 20.04, OpenSUSE 15.2)
    Pi4 with Ubuntu MATE 20.04
    Unix since 1974 (pdp-11, Interdata, AT&T, Tandy, Convergent, Sun, IBM, NCR, and HP)
    Linux since 1995 (Mandrake, Redhat, Fedora, CentOS, OpenSUSE)

  2. #22

    Question Re: Partition Table Not Recognized in USB -C Enclosure

    Quote Originally Posted by hcvv View Post
    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!
    - Itai
    https://www.cybernium.net

  3. #23

    Default Re: Partition Table Not Recognized in USB -C Enclosure

    Quote Originally Posted by larryr View Post
    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!
    - Itai
    https://www.cybernium.net

  4. #24
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    406

    Default Re: Partition Table Not Recognized in USB -C Enclosure

    Quote Originally Posted by idanan View Post
    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.
    OpenSUSE 15.2 with VirtualBox VM's (XP, 10, Ubuntu MATE 20.04, OpenSUSE 15.2)
    Pi4 with Ubuntu MATE 20.04
    Unix since 1974 (pdp-11, Interdata, AT&T, Tandy, Convergent, Sun, IBM, NCR, and HP)
    Linux since 1995 (Mandrake, Redhat, Fedora, CentOS, OpenSUSE)

  5. #25
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,195
    Blog Entries
    1

    Default Re: Partition Table Not Recognized in USB -C Enclosure

    Quote Originally Posted by idanan View Post
    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:

    Code:
    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:
    Code:
    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:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •