It looks like they wasn't. I re-formatted it using
fdisk -H 224 -S 56 /dev/sdX
as adviced here and let the first partition start at the offset 58720256 = 56 * 2**20 (so losing 58MB). Now, parted doesn't even start (message "Can't have a partition outside the disk!"), but the disk works fine and according to my limited knowledge and to the calculator, everything's fine.
root@ubuntu:/home/ubuntu# sg_readcap --16 /dev/sdd
READ CAPACITY (16) not supported
This means when your USB docking translate the capacity from the drive's ATA IDENTIFY DEVICE data (seen in hdparm -I
/ smartctl -i
), it can at most report a size up to 32-bit (i.e. 0xffffffff, 4294967295) in terms of number of logical sectors. This is an inherit limitation of SCSI READ CAPACITY (10):
Logical Sector Size | Maximum capacity supported (TiB / TB)
512 | ~2.0 / ~2.2
4096 | ~16.0 / ~17.6
Since your drive is an AF 512e drive that has totally 5860533168 / 0x15d50a3b0 512-byte logical sectors, which requires 33 bits to represent, only a SATA/USB bridge that supports SCSI READ CAPACITY (16) can handle it properly. When the size is truncated to 32-bit, it turns from:
101011101010100001010001110110000 (5860533168)
to
01011101010100001010001110110000 (1565565872)
The Linux kernel, or probably all OSes, will basically never issue ATA IDENTIFY DEVICE command "directly" (i.e. encapsulated in a SCSI ATA PASS-THROUGH command) to USB drives, but SCSI READ CAPACITY commands (which you issued manually with sg_readcap
), to get the capacity of them.
Only when the drives are actually SATA drive connected with a SATA/USB bridge, the command will be handled by the SCSI-ATA Translation Layer implemented in the bridge, which will then issue ATA IDENTIFY DEVICE command to the SATA drive to get the information it needs to form the response data for the READ CAPACITY command.
But utilities like hdparm
and smartctl
are (almost) exclusively for ATA drives, so they pretty much do everything with ATA PASS-THROUGH. (Also because they are userspace utilities, it is expected you, the user, will only use them on the appropriate type of devices.) That's why you end up getting different capacity in different places.
Best Answer
I bet you created a GUID Partition Table (GPT) on the disk to get the "last usable sector" number.
Did you notice that the last usable sector is 34 sectors less than the total number of sectors?
Check this out:
(source)
Those "unusable" 33 sectors are actually for the backup GPT! (That's LBA -34 to the end.)
We can also derive why the last MiB-aligned sector and the last I/O block aligned sector are the way they are.
Note: You likely arrived at your last sector numbers without using a GPT. The legacy MS-DOS partition table only takes up 512 bytes (1 logical sector) at the beginning of the disk with nothing at the end.
Disk Information
Physical Block Alignment
Your last aligned sector: 976773167
1MiB Block Alignment
Your last aligned sector: 976773119