6

The GPT (GUID Partition Table) is the most accepted modern standard for partitioning of a data storage device. Its unit for the offset and size of a partition is so-called sector*. Is it a well-defined unit? No, it isn’t. Firstly, one can switch a storage device from the “512-byte logical sectors” mode to the 4096-byte sectors and back using ATA or NVMe commands [2]. Secondly, the same device can be connected to its host via various interfaces, possibly performing a sort of native-to-logical sector translation. Let alone yet another scenario: a byte-for-byte backup of a 4096- or 2048-byte-sector medium to, say, a 512-byte-sector HDD.

But what do we see in the GPT header [3]? Signature, Header size, Current and backup LBAs, First and last usable LBAs for partitions, Disk GUID, Starting LBA of partition entries, Number of partition entries, Size of a partition entry, CRC32… all the stuff except for the sector size, which is critical for interpretation of the following partition data.

The GPT record [4] at LBA 0 (historically the master boot sector) has it neither, although there is enough room for any information the developer could deem helpful.

Yes, a skilled programmer can observe that the “sector size” can be inferred as the actual offset of a header (in octets or so) divided by its “Current LBA” value. Is it enough for sane error checking? Unlikely, because several “GPT headers” can be present on the same medium, such as one at 0x200 assuming 512-byte sectors and another at 0x1000 assuming 4096-byte sectors; both claiming to reside at LBA 1. 𝙸 can’t invent a plausible story how such disposition would lead to a trouble just now, but see no reason why such a possibility should be discounted.

Do you see any rationale behind omission of the sector size in any of the GUID Partition Table structures? Especially, at certain (fixed) offset on the medium, because specifying it only in the GPT header (having variable offset, counted in octets) has no merit, as explained above. Such possible rationale as a reliable and relatively simple algorithm (to prevent confusion) usable by disk partitioning tools and OS kernels. Or should we see it as a stupid gaffe by the developers from c. 2000? Economy obviously couldn’t be a concern.
Those who deem that 512-byte sectors were universal during the (U)EFI development time: no, they weren’t. Random-access media having 2048-byte sectors were already developed [5] and commercially available no later than in 2001 [6], and not only CD-ROMs. One haven’t necessarily be a genius to foresee various interoperability problems.

Special clarification:
* Physical layout of the stored data is irrelevant to the essence of this question. We won’t look at anything beyond interfaces used (by UEFI or OSes) to access the data.

Improve this question
10
  • 3
    This is a well researched and answerable question. I discourage closing.
    – candied_orange
    Commented Oct 18 at 9:54
  • 1
    GPT does not work with hardware. It is a high-level logical structure just like filesystems it contains. Why would it mention or use sector or any other physical information? The sector information may be important on device driver level, but not on filesystem level.
    – Basilevs
    Commented Oct 18 at 11:58
  • 2
    @Basilevs: that sounds like the start to a good answer.
    – Greg Burghardt
    Commented Oct 18 at 12:30
  • 1
    @Basilevs so? Do you think the devels had to use octets as the unit? One of the drawbacks would be restriction of the storage volume to 16 EiB = 16,777,216 TiB (assuming 64-bit addresses), although others likely exist too.
    – Incnis Mrsi
    Commented Oct 18 at 12:38
  • 1
    @Basilevs before getting to files on the EFI System partition (which contains in its first sector, like any well-formed FAT partition, necessary information on sizes and offsets), we have to find that sector. The GPT provides us with its LBA in units of “sectors”. Should we “really use sector-based addressing” indeed?
    – Incnis Mrsi
    Commented Oct 18 at 16:48

2 Answers 2

Reset to default
4

A software layer which can read and write the GPT has to use low-level ATA/ATAPI commands for it. Hence, it can simply ask the device for its logical sector size using the ATA command "IDENTIFY DEVICE". There is simply no need to store the sector size redundantly on a higher logical layer.

Changing the logical sector size of a storage device afterwards will usually invalidate the whole data layout as well as the GPT itself. This is an operation which has to be done once before using a device, and then never again - until the whole device gets erased completely and prepared for usage in a different environment. Hence a user of the GPT can safely assume the sector size reported by the device to be constant during the life time of the GPT.

Of course, Intel (who developed the GPT standard) could have made the decision to store the size redundantly on the GPT level, and today we can only speculate about why they designed it the way it looks today. My best guess here is that they decided to keep a strict separation of responsibilities of the different layers - sector size belongs to the device layer, partition layout (measured by number of sectors) to the GPT layer. Storing the sector size in the GPT breaks the idea of having a single source of truth for this crucial piece of information.

Improve this answer
6
  • So devices routinely reporting "obsolete' 512b sector size despite physical sector size of 4k can't be used with larger sectors? Or is there a separate logical chunk size on filesystem level?
    – Basilevs
    Commented Oct 20 at 11:07
  • 1
    @Basilevs: Annex D, section D.5.4.3 at the document I linked to says "There are many file systems that cluster sectors together to create an allocation unit larger than a single 512-byte logical sector." - but don't ask me which of the popular file systems does this how precisely. I am sure you find all this information online for the commonly used file systems.
    – Doc Brown
    Commented Oct 20 at 15:54
  • A reasonable take (and 𝙸’m unsure why someone downvoted here). Just for the record: the world of WWW disparages this principle of separation of responsibilities of layers since early 2000s, although HTTP envisaged it. Browsers are known to dismiss the Content-Type label for images, resorting to data-based heuristic. There are even worse abominations, such as the first 3 octets in a text/* document overriding its charset (promulgated by Anne van Kesteren of Mozilla) which resulted in a broken text/plain support by virtually all browsers made since c. 2012.
    – Incnis Mrsi
    Commented Oct 22 at 9:34
  • @IncnisMrsi: I would be careful to draw such comparisons. A meta data standard like GPT is made for things several orders of magnitude less complex than a web standard like HTML, and AFAIK it was created by a single organization, not by a multitude of stakeholders. Large-scale systems, however, require a certain amount of redundancy. Fully redundancy-free design does not scale up beyond a certain size. BTW, my answer did not get any downvote (yet).
    – Doc Brown
    Commented Oct 22 at 11:18
  • So how does the ATA device know the logical sector size, which is as far as I understand us independent on any formatting?
    – gnasher729
    Commented Oct 25 at 16:35
-2

Your drive is an array of sectors, numbered from 0 to (end of drive - 1). The sector size can be 512 or 4096 bytes, we don’t know. How your hardware accesses data is irrelevant.

Sector 0 is cleverly designed so that old master-boot-record software keeps its dirty fingers away from the drive and doesn’t touch it as nd damaged it. Gpt software ignores it.

Sector 1 contains the partition table header. Except you don’t know the sector size so you dont know where it starts. You may assume it starts at byte 512 or 4096 (or maybe 1024 or 2048 or 8192?). If you assume that the fake master-boot-record in sector 0 does not contain the signature “EFI PART” then you read from offset 512 and 4096 (and possibly other small powers of two) until you find “EFI PART” and current sector = 1, and the read offset is your sector size.

Storing the sector size outside sector 0 would not make a difference except giving you some extra redundancy. I would have stored it, I love redundancy:-)

Improve this answer
4
  • 1
    Does this mean that sector size is derived from marker offset?
    – Basilevs
    Commented Oct 18 at 18:51
  • 1
    𝙸 can’t go through this text full of confusion. Why and where could “the fake master-boot-record in sector 0” contain the signature “EFI PART” and LoLwhy “fake”? What does “you read from offset 512 and 4096” mean technically for an UEFI loader or an OS? Anyway, there is no stated answer to the principal question: do you see any rationale?
    – Incnis Mrsi
    Commented Oct 19 at 5:09
  • As for “… cleverly designed so that old master-boot-record software keeps its dirty fingers away from the drive…” — not in this context, indeed. Imagine a storage operated in the “512-byte logical sectors” mode (512e) with a GPT. A sudden change to a larger sector (1, 2, 4 KiB) mode happened. What does any partitioning software see? There is no more GPT at LBA 1 and the DOS/MBR contains one useless partition. An unlucky user edits the DOS/MBR table and fdisk, overwriting LBA 0, wipes all data at 0x2▯▯ out, destroying what has been the GPT header. What about “dirty fingers” now?
    – Incnis Mrsi
    Commented Oct 19 at 8:38
  • You clearly can’t just change the sector size. The GPT is at sector 1. Always. If I change sectors from 512 to 4096 then the GPT has to be moved from 512 to 1023 to sector 1 at byte 4096 to 8191. If you do that you overwrite the partition table so you have to move that. And then you overwrote the start of the first partition. It’s not a trivial operation.
    – gnasher729
    Commented Oct 20 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.