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

@Basilevs and you shouldn’t ignore that GPT is a component of UEFI. An UEFI boot loader namely “works with hardware” when fetches an appropriate executable from the boot partition.

@IncnisMrsi, logical unit size is in general unrelated to physical size (ignoring performance). Does UEFI really use sector-based addressing for bootloading? It seems to use FAT32 instead

@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?

@IncnisMrsi but those are logical sectors, not hardware ones. So bootloading has nothing to do with hardware.

@IncnisMrsi could you clarify in the question, that you are interested in logical sector size? I was confused by the middle of the question.

Where is definition of a logical sector presumed by @Basilevs?   ❝ LBA always refers to the drive's block size. So it may be 512 or 4096 or some other value, depending on what the drive reports. --Brian C. Lane ❞ [discussion]   Give your definitions and then 𝙸’ll about to clarify anything in the question.

To be fair I'm not aware of formal definition and there does not seem to be a standard. What I meant by "logical sectors" are sectors observed by tooling like in this article

I'm not sure what the quote about LBA means in conext of our discussion. Is it irrelevant given, that it is only provided for compatibility with older OS?

The example implies that the drive counts LBA in units of 512 bytes.

OK, 𝙸’ll edit to clarify that physical arrangement of data is irrelevant to the question.

@IncnisMrsi Drive can do whatever it wants, the OS is free to ignore that and use a different block scheme.

The OS may think whatever it wants, but it has to talk to the storage in a language acceptable for the interface, such as ATA, SCSI or NVMe. Moreover, the partition table shouldn’t rely on assumptions of any particular OS installed on the box. It should rely on things visible by a generic software running there.

what does the quote about LBA means in context, really? Didn’t the question explicitly state that possible errors may come from ambiguity in interpretation of LBA 1?

@IncnisMrsi Yes, I've meant software in general. The interface is important, but it is hidden from FS layer by device driver.

@IncnisMrsi For some reason, I was under impression, that LBA size is not important for GPT - it may be used to communicate to the disk by driver, but GPT works on higher level splitting octets anew. I don't want to look it up now, so I'm going to watch answers for your question :)

What is “driver” in UEFI? And moreover, a storage’s partition table shouldn’t be a toy for any particular OS family. It should provide interoperability.

@IncnisMrsi an abstraction over hardware specifics. Abstractions may be OS independent.

Yes, that’s one of the scenarios 𝙸 mentioned: a possible native-to-logical translation by a piece of hardware. But such sort of “abstraction” doesn’t make simplistic software (such as boot loaders) happy. Simplistic software would prefer LBA over the byte-stream abstraction for the storage.

@IncnisMrsi Sorry, I do not like the "piece of hardware" part here. This may as well be done by software. It does not really matter. I also don't see how anything is simpler than byte-stream.

Example of a problem (with boot loaders) is: what to do with requests to load a file located at an odd (in octets) absolute offset? Should the loader fail to do it? Should it work around available sector boundaries? Or should the device controller work around such crap? Sequentially numbered sectors having identical size are easy for both provider and user. Random-access with one-octet granularity is handy for the user, but a pain for the provider.

@IncnisMrsi Not a problem, as any software including UEFI, has plenty of layers. Some of those can couple/transform one format to another. I do not know how it is done exactly, sure, but as a reminder, UEFI can read FAT32, which is complex enough.

FAT is constructed of blocks (or sectors in the DOS parlance, whose size is indicated with a 16-bit little-endian at 0x2B) expected to be multiple of the device sectors. No file can start from an offset not multiple of the block size.

So what’s bad with fragmentation? A loop by clusters to load the entire file? Actually not even a performance penalty for a modern HDD where controller optimizes requests anyway. FATs (especially -16 and -32) are easy conceptually. They require few code; whereas any code is prone to glitches and bugs under edge conditions.

@IncnisMrsi nothing is bad with it. It is an example of complexity, that overshadows your block translation worries.