MBR/EBR Partition Tables

Copyright © 2004, 2007, 2013 by Daniel B. Sedory
NOT to be reproduced in any form without Permission of the Author!


  The Master Boot Record (MBR)

In the late 1970s and early 80s, many different microcomputer manufacturers were vying for their share of the market: Apple™, Atari™, RadioShack's Tandy™ (TRS-80) and others across the world had already found buyers when the IBM® Personal Computer™ arrived on the scene. By the time PC became a generic term for any personal computer, many were using some form of Microsoft's DOS. So, due to the sheer number of early PCs based on IBM PC DOS (which included all the "PC-compatibles" and those now running MS-Windows™ or distributions of Linux), the original PC's basic MBR structure (see table below) effectively became the default standard.[1]

The MBR (which is always located on the first sector of a hard disk) contains that disk's Master (or Primary) Partition Table; often the only partition table on many PCs today. The partition table comprises only 12.5% (64 bytes) of this 512-byte sector:

Basic Structure of the Master Boot Record Sector
Offsets (within sector)
(in bytes)
in Decimal
in Hex
000 - 445
000 - 1BD
Code Area
446 - 509
1BE - 1FD
Master Partition Table
510 - 511
1FE - 1FF
Boot Record Signature
Table 1.

Table 2. This should remove any confusion over what constitutes a valid Boot Record signature; sometimes called its Magic number, and often expressed as the 16-bit hexadecimal Word, 0xAA55 (or: AA55h) for the little-endian[2] PC.

Boot Record Signature
Offset (within sector)
Byte Values
( Hexadecimal )
in Hex


Primary Partitions

This standard MBR structure has always contained a Partition Table with four 16-byte entries as follows:

The standard 64-byte Primary Partition Table
Offsets (within MBR sector)
(in bytes)
in Decimal
in Hex
446 - 461
1BE - 1CD
Table Entry for Primary Partition # 1
462 - 477
1CE - 1DD
Table Entry for Primary Partition # 2
478 - 493
1DE - 1ED
Table Entry for Primary Partition # 3
494 - 509
1EE - 1FD
Table Entry for Primary Partition # 4
Table 3.

Thus, disks using this standard table can have no more than four Primary partitions, or as we'll describe in the next section, up to three Primary partitions plus one Extended partition. These early partitioning tools (called FDISK; short for Fixed Disk) even for DOS versions 3.30 and later, were programmed to create only a single Primary partition; though it was possible for other non-DOS primary partitions to exist, then multiple logical drives would be created within a single Extended primary partition. Under NT-type operating systems, such as Windows XP, Disk Management will allow three Primary partitions to be created, before requiring an Extended partition for more logical drives.


A Partition Table Entry

Both the MBR and Extended Boot Records use the same general format for entries within their partition tables:

Structure of a 16-byte Partition Table Entry
Relative Offsets
(within entry)
Boot Indicator (80h = active)
1 - 3  
Starting CHS values
Partition-type Descriptor
5 - 7  
Ending CHS values
8 - 11 
Starting Sector
12 - 15 
Partition Size (in sectors)
Table 4.

Since disk editors often display 16 bytes per line starting with offset 000 and partition tables begin at offset 1BEh within these sectors, it's highly likely you'll see the entries overlapping each display line. For example, here's a simple (single entry) MBR Partition Table with columns for the offset of each 16-byte line and its individual bytes of data, followed by the DOS characters representing (if possible) each of those bytes (or a 'dot' for those bytes with no simple ASCII equivalent):

Offset  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F   ASCII characters

  1B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01   ................
  1C0  01 00 0B 1F 3F 33 3F 00 00 00 41 99 01 00 00 00   ....?3?...A.....
  1D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
  1E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
  1F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA   ..............U.
Table 5. Hexadecimal display of bytes within an MBR sector's Partition Table; its first
and only entry has been highlighted in light green and the MBR Boot signature in yellow.

Due to the prevalence of utility tools, such as Power Quest's Partition Table Editor [3], techs are rarely required to manually decode then re-encode an edited entry; but even if they were, the ever increasing size of hard disks, usually makes this task much easier now. For the sake of completeness, we'll explain all the details here for decoding a partition table entry (compare with Tables 4 and 5 above):

1.Boot Indicator. In this case, it's 80h, but you'll rarely, if ever, see anything except 00h in Extended Boot Records. Technically, only the "Active" (bootable) Primary partition is ever supposed to have its 'high bit' set (making that byte, 80h). Some boot managers might allow logical partitions to be set active, but more likely a boot manager will never use this indicator when doing so.

Starting Sector  in CHS values (3 bytes). These values pinpoint the location of a partition's first sector, if  it's within the first 1024 cylinders of a hard disk. When a sector is beyond that point, the CHS tuples are normally set to their maximum allowed values of 1023, 254, 63; which stand for the 1024th cylinder, 255th head and 63rd sector, due to the fact, cylinder and head counts begin at zero. These values appear on the disk as the three bytes: FE FF FF (in that order).

Note: These bytes are somewhat in the order of Head, Sector and Cylinder, but the cylinder value requires more than 8-bits (one byte) and the sector value uses less than 8-bits, making this conversion rather difficult at times. The 01 01 00 in our example above, stands for CHS (0, 1, 1)  or LBA Sector 63; the 64th sector on the disk, since its count begins at LBA 0 [4]. The 3-byte Ending CHS values will be dealt with in detail under the Decoding CHS Values section below.

3. Partition Type Descriptor. Its single byte allows for only 256 possible values to indicate all types of partitions that can exist under the DOS/Basic Disk partitioning scheme. In this case, 0Bh, indicates a FAT32 file system. See our page here on: Partition Types.

4. Ending Sector  in CHS values (3 bytes); 1F 3F 33 in our example above. See: Decoding CHS Values.

5. Starting Sector (4 bytes). LBA (Absolute Sector) value. This value uniquely identifies the first sector of a partition just as Starting CHS values do. But it does so by using a 4-byte Logical Block Address (starts counting from Absolute Sector 0), which means it can locate the beginning of a partition within the first  FFFF FFFFh or 4,294,967,296 sectors, for hard disks up to about 2,199,023,255,552 bytes (exactly 2,048 GiB)!

Well, if that's true, then why did many computers have a limit problem at about 137 GB? Because many BIOS chips use only 28-bits for this value (a Hexadecimal number of FFF FFFFh or exactly 128 GiB) instead of the 32-bits used by partition tables! See 6 to 64 Bits: Hexadecimal Numbers Significant to Drive/Partition Limits for more details.

When you obtain all 4 bytes of this value (as stored on a little-endian[2] computer), the byte-order must first be reversed. So, for our example above, the: 3F 00 00 00, becomes only: 3F hex. This means that our first (and ony) partition begins at Absolute Sector 3Fh, which is also LBA 63 (or the 64th sector on the disk). This is the first possible boot sector for any drive having 63 sectors per head/track.

Partition Size in Total sectors (4 bytes). As with the Starting Sector values, these four bytes allow for a number up to 2,048 GiB for the size of each partition, and are also stored on disk in little-endian. So the stored bytes, 41 99 01 00, become: 19941 hex, for a size of: 104,769 sectors, or at 512 bytes/sector that's: 53,641,728 bytes (or only about 51 MiB).


Decoding CHS Values

Although a Head number is fairly easy to compute (it's always whatever value [plus 1] is in the first byte of either the CHS Starting or Ending 3-byte fields), the Sector and Cylinder numbers are encoded into an odd arrangement of 6-bits and 10-bits, respectively, within the second and third bytes; making them more difficult to work with. The following diagram (see explanation below), attempts to make both the layout of a 3-byte CHS tuple and how to decode its numbers, visually clear:

CHS Bytes

Figure 1.  A 3-byte CHS field encodes Cylinder (10-bits), Head (8-bits) and Sector (6-bits) values.

How to decode the three CHS bytes: The 8 bits (1111 1110) shown in the "Head" byte equal FE in hexadecimal (or 254). Since their count begins with Head 0, this refers to its 255th head. The "Sector" value is computed from the first six bits (starting with the least-significant bit, bits 0 through 5). Thus, the second CHS byte (BFh) yields: Sector 3Fh (or 63); from the bits: 11 1111.

The Cylinder value, which is 10 bits in length, receives its two most-significnat bits (10, in this case) from those of the second CHS byte (1011 1111 = BFh), but retains the original third byte (D3h, in this case) as its lowest 8 bits. The result, 10 1101 0011, gives us 2D3h, or 723, as the Cylinder value. Thus, the CHS tuple in the diagram above, for some partition's Ending Sector is: (723, 254, 63).

The CHS Ending Sector, 1F 3F 33 in Table 5, for a roughly 53.6 MB partition, is decoded as follows:
Byte 1. 1Fh = 31.  (There are only 32 heads per cylinder for this disk drive).
Byte 2. 3Fh = 63.  (0011 1111); no significance to bits 6 and 7 (both are zero); 63 sectors per head.
Byte 3. 33h = 51.  (Bits 6 and 7 of Byte 2 --> bits 8 and 9: 00 0011 0011 for a cylinder value of 51).
Thus, the data above corresponds to an Ending Sector CHS tuple of: 51, 31, 63 (for 52 cylinders, 32 heads and 63 sectors). If you had a Partition Table calculator, you'd find that's equivalent to LBA sector: 104,831, and LBA 104,831 - LBA 62 = 104,768; the same size of the partition in sectors we arrived at when computing it from the "Partition Size" entry above!


For partitions which begin or end beyond  the 1024th cylinder, the three CHS bytes should always be filled with: FE FF FF ; which are decoded as follows:

Byte 1:  FEh = 254  for a total of 255 heads.

Bytes 2 and 3:  FFh and FFh — split into two full binary counts of 6 bits (11 1111; 3Fh = 63 sectors), and 10 bits (11 1111 1111) or 3FFh = 1023 for a total of 1024 cylinders. CHS: 1023, 254, 63.

This tuple corresponds to an LBA sector of: 16450559. That's a point where about  8.4 GB of hard disk sectors could be accessed (16,450,560 sectors * 512 bytes/sector = 8,422,686,720 bytes).

16-byte partition table entries can not exceed 1024 cylinders for their Starting and Ending CHS bytes!  When utility programs display CHS tuples with a cylinder value larger than 1023, they can only do so by computing pseudo-CHS values from the 4-byte "Starting Sector" or "Partition Size" values.



Extended Partitions

If a hard disk's MBR has an Extended Partition entry in its Master Partition Table, then each Extended Boot Record (EBR) must also be examined.

It's very important that you understand this: Any Extended partition entry in the MBR, only describes what can be thought of as an envelope (or a black box) which might contain up to 23 Logical drives under the older IBM®/Microsoft® DOS 3.30 (or later) operating systems; and possibly more under Windows 2000/XP or some other operating system (Linux, e.g., does not use drive letters for its partitions). The point is: Until some utility program or operating system reads the first Extended partition table (and any others it might link to) inside the Extended partition, it's impossible to know what's in there!

Before the release of MS-DOS 3.30, hard disk sizes were exceeding 120 MB, yet no popular operating system could access partitions greater than about 30 MB. So the industry had to come up with a solution that allowed consumers to use all that available disk space; and soon! HDD manufacturers were already advertising much larger drives would be ready in the near future, but a proven file system that could use all that space would take a much longer time to produce. What the IBM and Microsoft programmers came up with was a solution that was still compatible with all existing Master Partition Tables, but allowed for more than a single DOS partition to be created: One of the four possible Primary partitions would become a special type, called an Extended partition, that could have its contents divided into many logical drives that could all be accessed by the operating system!

Extended Partition entries usually have Partition Types of either 05h or 0Fh; depending upon the size of the disk.

The following diagram shows a typical 40 GB HDD with a small FAT32 partition at the beginning of the disk. The remainder of the disk is enclosed within an Extended partition:

Figure 2.

The only way to figure out just how many Logical Drives there are within an Extended Partition is by jumping to each Extended partition table in the Extended Boot Records until you've found the last EBR table. These EBRs can be described as being chained together by each link to the next EBR table from its previous link. Therefore, to obtain the complete layout of any hard disk that contains an Extended partition, you need a copy or a summary of the data in the Extended partition tables of each EBR as well as the Master Partition Table!

Next Page -->



1[Return to Text] Deviations from this standard table structure may exist on some systems: Around the time of MS-DOS 3.30, the NEC Powermate could use a special eight-entry table, and later on, PTS-DOS, first developed in Russia, used a special fifth entry preceding the common 64-byte table (both the free demo of PTS disk editor and its successor, the original Acronis disk editor, display references to this entry; which, coincidentally, conflicts with the location of the Windows NT Disk signature).

NOTE: Neither the "Dynamic Disk" partitions of Microsoft Windows 2000/XP/2003 (rather than the more usual "Basic Disk" partitions), nor the special GUID Partition Table (GPT) which may be used by a Microsoft Windows 7 or 8 install (part of the new EFI spec) employ the MBR partitioning scheme described on this page. However, both of those partitioning schemes do create a "protective" MBR sector with special entries to keep previous operating systems and partitioning tools from overwriting any data in their GUID partitions. See our page on the GPT Protective MBR and EFI Partitions.

2[Return to Text] [Return to: Starting Sectors] Any IBM-compatible ("PC") computer (whether its CPU is an Intel®, AMD® or some other manufacturer's processor), has what's known as a little-endian memory architecture; as opposed for example, to the big-endian architecture of the Motorola® processors in a Macintosh or PowerPC system. This Little-endian architecture refers to the order of the bytes found in memory (or on a storage medium) for hexadecimal numbers composed of more than a single byte; where the least-significant byte will occur at a lower (or preceding) position than its most-significant byte (or any more significant bytes in-between). Thus, the Hex number, 38DA75C6h, as seen in a PC's memory would occur as: C6 75 DA 38; whereas, a Big-endian system simply has: 38 DA 75 C6. This order was established so the first little-endian processors could start working on arithmetic problems as soon as the first byte of a large number was accessed; basically the same as we do when adding the least-significant digits of two large numbers first, carrying any remainder over to the next column, and finally adding together the most-significant digits last. (Cf. our note on Microsoft's very confusing way of referring to hex numbers in documentation and on their web site by using their own nonstandard definition for little-endian Hex numbers! )

Note: Contrary to what some sites may state, although Jonathan Swift did use the term "Big-endian" in his work, Gulliver's Travels, you'll never  find the term 'Little-endian' in that text. Swift used "small" and "small end" and even "larger end" before mentioning the "Big-endians," but never wrote, little end. It's easy to search the whole book online as proof. Chapters Four and Five (of Part One) contain most of the terms he actually used in relation to our discussion. The incorrect references might be due to Danny Cohen's paper, Internet Engineering Note (IEN) 137: "On Holy Wars and a Plea for Peace" (1 April 1980) in which (see his Appendix) he not only used the phrase "little end" (instead of "small end"), but repeatedly described the Lilliputians as being Little-Endians; though Swift never used that term. For further studies on Endianness, see the Endian FAQ (which includes Cohen's paper).

3[Return to Text] This tool was available from Symantec's FTP site, but no longer! It was removed; as were all utility programs made by PowerQuest: ftp://ftp.symantec.com/public/. The Windows™ version of Partition Table Editor is no longer located here:
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip .  A DOS version is also available; which could be used on hard disks containing only DOS or to check the partitions made by Linux or some other OS. We've even used this DOS version to test MS-DOS 3.30 partitions under BOCHS! The old demo of PTS-Disk Editor is also quite nice for quickly checking Extended partitions under DOS.

4[Return to Text] To thoroughly understand how CHS tuples correspond to LBA values for the same sectors on a disk, we recommend downloading a handy little Windows™ utility, PT Calc, which we've made available here. (The original version can still be found elsewhere on the Net (as ptcalc.zip), but its window will appear in the lower-right hand corner of a 1024x768 screen size.)

Next Page -->

Updated: July 22, 2007 (2007.07.22); February 21, 2009 (2009.02.21); December 9, 2012 (2012.12.09); March 2, 2013 (2013.03.02); January 21, 2016 (2016.01.21).
Last Update: February 11, 2018. (2018.02.11)

You can write to us here: contact page (opens in a new window).

MBR and Boot Records Index

The Starman's Realm Index Page