To prove this one way or the other, you would need to dump the first 512B of the drive into a hex editor and manually decode the part table to determine what is there for the start sector on a partition for LBA addressing. I'd like to see something more black and white stating that the OS does logical/physical address translation and why does the part table show 512B sectors? For this reason I would not take the chance on a > 2TB drive with a msdos/mbr part table, I'd always use GPT. So I have a partition table and size based on the standard 512B sector size, but a statement suggesting the OS is using 4096B sectors to address the drive. dev/sdc2 : start= 2048, size= 3863816192, type=83Īnd calculate the size based on the number of sectors, the sector size is 512B. Each time the OS says "hey, you, disk, write me these 512 bytes to offset xxx" the disk will use up 4096 bytes to store these 512 bytes (the rest being zeros or junk data, assuming you don't end up with a memory underflow) because they don't communicate in bytes, they communicate in sectors.Ĭode: Select all ~ $ pkexec sfdisk -dump /dev/sdc The only catch is that if the OS isn't aware that this is a magic disk that uses 4096 sectors instead of 512 byte sectors, there's going to be a mismatch. Suddenly, our 2TiB limit is upgraded to 2^32 x 4096 bytes, or 16 TiB, without having to ditch MBR, switch to UEFI or GPT, or anything! When an OS says "give me the 2nd sector on the disk" by requesting LBA 1 (because LBA 0 is the first), we aren't going to give it bytes 512 - 1023 but rather bytes 4096 - 8191. But recently, hard disk manufacturers realized there's an opportunity to work some magic: take the traditional CHS or 32-bit LBA and simply replace the sector size with 4096 (4k) instead of 512 bytes. From day one, it has been 512 bytes and it's stayed that way ever since.
See, throughout all the limitations discussed above, one thing has been a fixed assumption: the sector size.
0 kommentar(er)
