0

Short version: If the MBR is only 256 bytes and the partition table is 4 bytes, what fills all the space between the beginning of the device and the start of the first sector on it?

More information: When I run sfdisk -l /dev/sda (which is the system drive on this Pi system), I get:

Disk /dev/sda: 117.2 GiB, 125829120000 bytes, 245760000 sectors
Disk model: USB DISK
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: 0x45d5fb5b

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1  *      8192    532479    524288  256M  e W95 FAT16 (LBA)
/dev/sda2       532480 245759999 245227520  117G 83 Linux

I wanted to be clear the Start and End columns are in sectors, so I did quick math: 532,479-8192 = 524,287. One less than the 524,288 number for total sectors in sda1, so looking at the start being sector 8,192, that works out and tells me that the Start and End columns are given in sectors. If a sector size is 512, that means if we start with sector 0 (and I don't know if that's correct), there are 8,192 blocks before the first partition, or 4,194,304 bytes, or 4MB.

If the MBR is 512 bytes (which includes the partition table), what is in the rest of that 4MB at the start of the device?

I'm working on a drive copy script for Pis (so it only works with MBR drives - at least for now), and I know I have to copy the partition table, data in the partitions, and the MBR. I'm wondering what else is in that space up front and if that data is best copied over to the new block device.

Improve this question

1 Answer 1

Reset to default
2

If the MBR is 512 bytes (which includes the partition table), what is in the rest of that 4MB at the start of the device?

The MBR is 512 bytes. The rest of the block at the beginning is garbage/nothing. This is a standard practice with SD cards as they typically have 4 MiB "erase blocks"1. You can verify this with:

> cat /sys/block/mmcblk0/device/preferred_erase_size 
4194304

If you look at a fresh out of the package SD card, you'll notice the same offset was used at the factory (presuming an MBR format, GPT will have a bona fide special partition at the start).

In the case of a USB device used as the boot-from primary storage, this pattern is duplicated because that's how the OS image is -- it contains two partitions that are copied as a whole, ie., a formatter (or normative manual methodology) will not create the two partitions then copy data into them.

I'm wondering what else is in that space up front and if that data is best copied over to the new block device.

It isn't worth fussing over, so it might as well be copied (as opposed to coming up with some new layout). But it isn't used for anything AFAIK.

  1. You'll find lots of explanations of what an erase block is online, eg. https://together.jolla.com/question/179054/how-to-creating-partitions-on-sd-card-optionally-encrypted/

    Basically, when data is changed, an entire such block is removed and then replaced because that's how NAND flash works (see under Background on aligning data-structures on FLASH-based mass storage from that link, "Not aligning data-structures to the erase-block size (or multiples of it) results in a much higher write amplification, leading to vastly degraded lifetime and lower performance of a reformatted SD-card.").

Improve this answer
3
  • I take it this practice is always used in creating Pi images, since this is on a USB stick? (Which doesn't have a preferred_erase_size.) Am I right that the thinking would be that for so many Pi systems, the system would be on a microSD card that it's just treated as a standard to leave that space blank? Also, this also says to me that if I have to copy raw binary, it's only for the first 512 bytes? (I've had problems booting my copies until I started copying the start of the source to the destination device, so, apparently, sfdisk does not give me the MBR info needed.)
    – Tango
    Commented Jul 25, 2023 at 18:54
  • Sorry, I overlooked the fact that this was a USB device, and have edited in a paragraph to reflect that. It's because that's how the OS source image is, as you say primarily intended for SD cards; the image is a storage device image containing two partitions and the MBR with offset, it isn't a singular filesystem. It's then copied block for block onto whatever device. The offset in that case may not be as important, but it won't do any harm (pretty much any device will have blocks/sectors/whatever that will align to 4 MiB).
    – goldilocks ♦
    Commented Jul 25, 2023 at 19:04
  • Thank you! I'm thinking I'm better off copying that block with dd, then using sfdisk, since copying it later would overwrite the new partition information (and maybe more). And, as to the extra data - yes, you're right. Might as well copy it in case it's useful in some way. Or I can always use that space to slip in "Paul is dead" written backwards as a joke about the Beatles and secret messages in media...
    – Tango
    Commented Jul 25, 2023 at 19:11

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.