DISK DRIVE TERMINOLOGY

start of: http://thestarman.narod.ru/asm/mbr/DiskTerms.htm

Terminology and Physical Description
The usable surface area of a hard or floppy disk is divided into a number of inv
isible concentric rings called tracks (see Fig. 1). And each track is divided in
to the same number* of small arcs called sectors. If a drive has more than one p
latter (or surface) that can store data (such as a double-sided floppy disk), th
en all the tracks that are located in the same position on each platter (or side
of a disk) are collectively known
as a cylinder. Data is read from or written to a disk drive's platter by a head
on the end of an actuator arm.
* In reality, the manufacturers of modern hard disk drives vary the number of se
ctors per track, increasing the total by thousands of sectors for the larger tra
cks (those closer to the outside edge of the platters). This is called zoned rec
ording. Since the size of the magnetic domains that can be written to/read from
a platter have become just a tiny fraction of those on the first hard disks, the
re would be a huge amount of wasted space between them if the longer tracks were
limited to the same number of sectors as the shortest (innermost) track!
NOTE: If an HDD platter/disc (or floppy diskette) has only one usable side, then
the term cylinder becomes pointless since it will refer to the same physical lo
cations as the term track; we'll comment on this later, under the section on cal
culating the capacity of a drive. Another important point: the terms head and si
de were often used interchangeably when computing the capacity of very small dis
k drives. Thus, sectors on a disk might have been referenced as being either Cyl
inder x, Side y, Sector z or as Cylinder x, Head y, Sector z. The most common
method (and the one used by the BIOS and many utility programs) is to specify by
CHS (Cylinder, Head and Sector; in that order). However, some old timers in the
computer industry still have a tendency to use the term Side; especially when d
iscussing Floppy Disks.
The Location of an MBR or Boot Record
After a PC's BIOS eliminates the possibility of a floppy disk boot, control is p
assed to some code in Memory that comes from the contents of the very first sect
or of its first physical Hard Disk. The code contained in that sector is most of
ten* that of the OS's MBR (Master Boot Record). This location can be referenced
as either Absolute Sector Zero (0) or as CHS 0, 0, 1.
_________________
* There are many Boot Manager programs and some viruses (called stealth boot vir
uses) that may be found occupying the first sector instead. The code of early BI
OS chips (in most PCs sold before 1995) couldn't recognize more than about 528 M
B (or exactly 504 Binary-MB; see below for the details) of any drive that happen
ed to be larger than that. When HDD capacities suddenly became much larger, 'dri
ve translation' software such as EZ-DRIVE (also called EZ-BIOS) by StorageSoft,
Inc. (distributed by Microhouse); and now owned by Phoenix Technologies, or MAXB
LAST by Maxtor, etc. was often installed in the first sector and beyond. This ty
pe of software is known as a DDO (Dynamic Drive Overlay). Note: In some cases, a
computer manufacturer might even replace the MBR with their own special softwar
e; although the tendency today is to reprogram the BIOS chips instead, making su
re their logos and data cannot be easily changed.
There is no MBR on a Floppy Disk. The very first sector of a 'Floppy' may or
may not contain the Boot Record for an operating system. If it does, the disk m
ust contain all the necessary files to boot that OS into Memory, or it cannot be
considered a bootable floppy disk. [See the MBR Index page for more information
on Floppy Disks.]
Here's a simple diagram that shows the beginning of an HDD (for either an NTFS o
r FAT32 file system as its first partition); its sectors are shown as a linear d

isplay (from left to right), but are not to scale. The digits near the top (in b
lue or green) refer to Absolute Sectors:
The OS Boot Record for the first (or only) partition on a hard disk is usually f
ound at Absolute Sector 63* (the 64th sector on the disk drive) and following; t
hat's also at CHS = 0, 1, 1 for any drive, or Absolute sectors 63 through 125. [
Note: Referencing a particular sector using the CHS system of early BIOS design
is technically limited to only the first 16,450,560 sectors; the so-called 8.4 G
B limit, even though you will see many utilities listing the number of cylinders
well over 1024.] An NTFS partition has a Boot Record that's 16 sectors long (N
TFS Boot Sector), and its MFT (Master File Table) begins at Absolute Sector 79 (
or Logical Sector 16). A FAT32 partition has a Boot Record that's 3 sectors long
(FAT32 Boot Record) in Logical Sectors 0 through 2, followed by a few zero-byte
sectors plus a "Backup Boot Record" in Logical Sectors 6 through 8. But just as
we found for all NTFS volumes, a Windows OS reserves many extra sectors for FAT3
2 partitions as well: The OS may never make use of this area (we've seen no indi
cation that it ever does)! It's comprised of 23 sectors that are all filled with
zero-bytes (from Logical Sectors 9 through 31); it's located between the "Backu
p copy" of the FAT32 Boot Record and the beginning of the first FAT (File Alloca
tion Table; at Logical Sector 32).
___________________
*This location used to vary with the drive's SPT (Sectors per Track). On an old
(1993) 245MB drive having only 31 SPT (rather than the usual 63 SPT), the Boot R
ecord was found at Absolute Sector 31 (the 32nd sector). But that's something yo
u'll never have to consider with a modern HDD. It does, however, let you know wh
y most DDO software is never larger than about 30 sectors! Today, there's always
62 sectors of space available for a Boot Manager; but most of them would never
consider using all of the available space even today.]
________________________________________
Where is the so-called "Hidden Area" of a Hard Disk?
After an OS boots up, it almost always "hides" the first Track (Cylinder 0) of t
he first Side (Head 0); which obviously includes the MBR sector, leaving only th
e OS's Boot Record as the first logically accessible sector. This yields another
way we can reference the OS Boot Record: We would say that it is located at Log
ical Sector 0
for that partition (or volume).
IMPORTANT: To avoid a lot of confusion, you must first try to determine if a par
ticular sector is: 1) being referenced from an Absolute or Logical Sector as the
starting point (LBA or Linear references use these methods); both of which alwa
ys begin counting from Sector ZERO (0), or 2) if the the CHS method is being use
d to reference a sector which always begins counting from Sector ONE (1).
You must also NOTE the difference between Physical (or Absolute) sectors, and L
ogical sectors:
1) When discussing the MBR code, or any other code which gets loaded immediately
after the BIOS, you should refer to sectors using Physical (or Absolute) sector
numbers; after an OS has booted into Memory, these sectors are often inaccessib
le by many standard utility programs (such as MS-DEBUG).
2) When an OS Boot Record is being discussed, it's likely that the sector number
s in the text will be Logical (so sector 0, 1, 2, etc. might actually be the 64t
h, 65th, 66th, etc. physical sectors on that drive).
________________________________________
How an OS Boot Record gets into Memory:
After executing the POST (Power-On Self Test), the BIOS loads the MBR (Master Bo
ot Record) from your first HDD into memory at 0000:7C00 and then executes it. Th
e MBR is relocated to 0000:0600* , so it can load any Active OS Boot Record into
the same location it was in: First the MBR checks your HDD for an Active Partit

ion, then it loads the OS Boot Record into memory at 0000:7C00 and turns control
over to the OS Boot code. Finally, the OS Boot Record code loads the rest of th
e Operating System into Memory.
_______________
*This may not be the case with a Non-IBM/Microsoft MBR; for example, see the LIL
O MBR (which moves itself to a much higher location in memory; that being: 8A00:
0098 for the MBR we examined).
Disk Parameters
for drives under 8.4 GB (or BIOS
without Extended INT 13 Functions)
First, you should be aware that the Parameters for the Cylinders, Heads and SPT li
sted on hard drive labels haven't had anything to do with how they're physically
constructed inside for a very long time! The actual number of Sectors per Track
varies a great deal depending upon which part of the disc is being accessed: th
e innermost track or one of the longer tracks near the outer edge of a platter.
There are often just a few heads and many more cylinders (tracks) than listed. [
If you can't find any CHS parameters listed a drive, then look for the letters
LBA (it stands for "Logical Block Addressing") followed by a single large number
; that will be the Total number of Sectors for the drive. ]
Way back when most drives were still under 100 Megabytes, certain drive manufact
urers developed and began to implement an interface for the controllers of their
drives which allowed them to have a virtual maximum of 65,536 cylinders, 16 hea
ds and 256 SPT. Each drive soon had its own little onboard computer to translate t
he actual physical locations of sectors on the platter(s) into a pseudo set of C
ylinders, Heads and SPT that these HDD manufacturers had agreed upon. For exampl
e, a Western Digital Caviar 33100 drive of 3166.7 MB says it has 6,136 cylinders,
16 heads and 63 SPT. Obviously with only three platters inside (that's what the
first digit of the 33100 means), it's impossible for it to have more than six re
al heads (and may have only three)!
Unfortunately, the BIOS code for handling disks (which soon became an Internatio
nal standard for all PC programmers), had developed its own set of maximum specs
of 1024 cylinders, 256* heads and 63 SPT.
This caused all sorts of problems for PC users when they tried to increase their
drive sizes to anything more than about 528MB, because only the lowest common v
alues in each spec could interface with each other:
512 bytes/sector x 63 sectors/cylinder x 1024 cylinders/head x 16 heads = 528,48
2,304 bytes (or exactly 504 Binary-MB). Eventually, computer manufacturers had t
o turn to programmers to create new BIOS code which added yet another layer of t
ranslation, so all the old programs using the BIOS code could still be compatibl
e with these larger drives.
[ Note: This solution hit yet another barrier when drive capacity exceeded 8,422
,686,720 bytes (The 8.4 GB Barrier). And once again, computer manufacturers had
to have new code programmed for their BIOS chips. Soon there were drives of 30,
40, 60, and now over 200 Gigabytes that must be dealt with. And some of these ar
e again using a newer type of DDO software or having their BIOS chips reprogramm
ed with Flash utilities (since new BIOS code can often be downloaded from manufa
cturers via the Net)! These drives may be partitioned into smaller sections, and
those partitions may have completely separate Operating and/or File systems in
them. Different OSs are often booted independently at power-up (one at a time) u
sing various types of specialized MBRs (such as LILO or GRUB when a Linux OS is
installed) or some other Boot Manager software. ]
_________________
* That's 256 possible Heads; but not what's used in reality! There are 8-bits th
at can be used for the Head count and since its value begins with a zero and can
end with 255 (or FFh), it's possible to count up to 256 heads. So, I had always
wondered why various notes (which also agreed with my own experience) would say
that in practice the Partition Table in the MBR and the BIOS code used a value
of only 254 (or FEh) for a maximum of only 255 Heads. Well, some time after I'd st

arted using Ralf Brown's Interrupt List for Assembly projects, I came across thi
s little note under INT 13 Function 02:
"All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug which preve
nts booting on hard disks with 256 heads (FFh), so many modern BIOSes provide ma
ppings with at most 255 (FEh) heads."
[INTER61 Copyright1989-2000 by Ralf Brown].
So, this was all because of a bug in MS-DOS which has been perpetuated by Micros
oft, IBM and the BIOS chip manufacturers just so you can still run MS-DOS x.x (for
whatever version this bug first appeared in) on the same PC you've got with an
OS that'd never be affected by it (Win 2000/XP, Linux or whatever)! This is yet
another lesson in how one possibly stupid mistake can change a technology for a
very long time! And this one will likely be with us until the CHS values are no
longer used by any current software (including all BIOS, OSs and programs), hard
ware, interfaces, etc., so I won't even guess at how long that might take!
Computing the Capacity of a Disk
A sector contains 512 bytes. This is the smallest amount of data that can be wri
tten to or read from a disk drive by most software.
The 1440 KB (1.44 Mb*) Floppy Disk:
The standard 3.5 inch PC floppy disk has two Sides or Heads; counting from Side
0 (which is on the bottom or hub side). There are 80 Tracks or Cylinders and 18
SPT (sectors per track). So it's capacity can be computed as follows:
512 bytes/sector x 18 sectors/track x 80 tracks/side x 2 sides = 1,474,560 bytes
or 2,880 sectors.
What's that? Your computer always says it has "1,457,664 bytes total disk space.
" Well, that's because you can't use the Boot sector, the two 12-bit FATs (File
Allocation Tables; of 9 sectors each) or the fixed-size Root Directory (of 14 se
ctors) for storing data! So you're left with 2,880 - 1 - 18 - 14 = 2,847 sectors
or 1,457,664 bytes for your files.
___________________
* This odd designation of 1.44Mb by Floppy Disk and/or Drive manufacturers is ar
rived at by rounding off
the actual capacity of 1440 Binary-KB (KiB) to an incorr
ect 1.44 Binary-MB ( just as they did for the 1200 KiB diskette by calling its s
ize 1.2 Mb ). I'm sure this has caused even more confusion among those trying to
figure out why their hard drive (or floppy diskette) has fewer total 'GB' (or '
MB') bytes than what's printed on the package!
[ See note above on the SI definition of a Megabyte. ]

Example: A 3.1 GB Hard Disk

The BIOS code from an early Pentium computer translates the specs from the 3.1 G
B drive mentioned earlier this way: The Sector numbers vary from 1 through 63 fo
r each Head, and the heads vary from 0 through 127 for each Cylinder. There's al
so a total of 767 cylinders on the drive; numbered 0 through 766 (But, the BIOS
might show a total of only 766 cylinders to the OS! More on this shortly). Thus,
the total capacity of the drive can be computed as follows:
512 bytes/sector x 63 sectors/head x 128 heads/cylinder x 767 cylinders = 3,166,
765,056 bytes (unformatted) or 6,185,088 sectors.
CHKDSK gives the usable space after formatting with Microsoft's 32-bit FAT
file system as: 3,156,418,560 bytes or 770,610 clusters ("total allocation unit
s") using a cluster size of 4 kb per cluster. (CHKDSK uses a Binary-Kb, so 1 clu
ster equals 4,096 bytes or 8 sectors. 770,610 clusters x 8 sectors/cluster x 512

bytes/sector = 3,156,418,560 bytes.)

NOTE: Microsoft's MS-DOS FDISK utility along with most third-party related softw
are (such as PowerQuest's Partition Magic) always follow whatever the BIOS dicta
tes as the Cylinder size of your HDDs. If the BIOS code was written to never mak
e use of the last cylinder of a hard drive, then these programs will do the same
. If you have a BIOS with more recent code (say after 1998), even your DOS softw
are should use all the cylinders! If you partition an HDD using Windows 2000/XP
or another modern OS such as Linux, then it will always make use of the last cyl
inder because these OSs are not dependent upon the BIOS code.
This whole problem is due to an historical practice started many years ago which
left that area available for certain test programs; thus, the name Test Cylinde
r. Wanting to be fair to the companies that make these utility programs, I'll po
int out that the reason for this is because they rely upon the BIOS to tell them
how many cylinders the hard disk has rather than querying the disk directly! Ne
wer utilities should no longer do this. Since the drive being discussed here (a
WD 3.1 GB) was partitioned with an MS-DOS FDISK program on an old machine, it ne
ver even knew the last cylinder was available; thus it leaves 63 sectors/head x
128 heads = 8064 sectors (or 4,128,768 bytes) reserved as a useless test cylinde
r.* Some utility programs will point this out. For example, when you check this
drive with the Ranish Partition Manager (ver. 2.37), it states:
Note that BIOS reports only 766 cylinders.
_________________
* NOTE however, that trying to reclaim this space might end up being a huge head
ache if you have to work with any computer that still has an old BIOS and/or old
er utility programs: Say you were given the task to set up a drive to be cloned
and it gave you the option of using the last cylinder (as Windows NT4 does), and
you did that. Well, after installing all of the software and getting things jus
t right, guess what might happen when you try to clone the drive to another one
of the SAME EXACT size? If the cloning software wasn't able to access the drive
directly or simply decided it must follow the BIOS, then it could easily refuse
to proceed; stating that the target drive was too small (by only 1 cylinder), be
cause it depends upon the BIOS for drive sizes! So, until all usable cloning pro
grams query drives directly and never use the BIOS, it's better to leave things
as they are on these older machines.
Now we can see where all of the space has been allocated: First, there's the tes
t cylinder's 8,064 sectors (at the end of the drive), the 63 so-called hidden s
ectors; being the first track (not cylinder) of the drive (which includes the MB
R at Absolute Sector 0). Then an MSWIN4.1 Boot Record's 32 reserved sectors (bei
ng this drive's only Partition) from Absolute Sectors 63 through 94. This is fol
lowed by two 32-bit FATs of 6,024 sectors each. The second FAT beginning at Abso
lute Sector 6,119. Finally, there's at least one sector (beginning at Absolute S
ector 12,143) reserved for the first of any number of Root Directory entries. (
Under the Windows 32-bit FAT File System, the number of Directory entries for th
e Root is only limited by the drive's available space. )
Therefore, of the disk's original capacity of 6,185,088 sectors, we have 6,185,
088 - 8,064 - 63 - 32 - 12,048 - 1 = 6,164,880 sectors (or 3,156,418,560 bytes
) of usable space before adding any files or directories to the drive.
Start of: http://thestarman.narod.ru/asm/mbr/DiskTerms2.htm
Disk Parameters
for drives over 8.4 GB and having a
BIOS with Extended INT 13 Functions
Disk Drives over 8.4 GB should reply to most direct access inquiries (using ATA
commands and coded I/O instructions) as having a drive geometry of: 16,383 Cyli
nders, 16 Heads and 63 SPT. (NOTE: This is not the same as the "geometry" used b
y computer BIOS, most utility programs or the Partition Table itself to refer to
drives over 8.4GB; see below!)

This should be true for all disk sizes over 8.4 Gigabytes! To find their true c
apacities, you can only use the Total number of Sectors (or LBA number). As a ma
tter of fact, the 20 GB drive we'll be examining lists exactly these three value
s (16,383, 16 and 63 as its own Cylinders, Heads and SPT). I have no idea why M
axtor did this, since this tells you almost nothing about the actual capacity of
the drive!
Western Digital, however, stopped using the terms Cylinder, Head and Sector on th
eir drive cases a long time ago, switching to just a single LBA ( Logical Block
Addressing ) number; for example, one of their 40 GB drives is labeled: LBA 78165
360 (which means there's a total of 78,165,360 512-byte sectors available on this
drive
for a capacity of: 40,020,664,320 bytes). That's very useful information
compared to the Maxtor drive!
In order to confirm our test drive's size, we had to search the Maxtor web site f
or the exact model number and found that the drive's Number of Cylinders was: 39
,704. But, that's based upon only 16 Heads and 63 SPT, so, after multiplying the
m together, that finally gave us an LBA of: 40,021,632 sectors. Hopefully, Maxto
r (and any drive manufacturers like them) will begin using this single LBA numbe
r in the future!
The Useless "Geometry" Values: Programs which use only the CHS method for calcul
ating partition sizes (including the CHS entries in the Partition Table of any M
BR or EBRs (Extended Boot Recrods) should now list all Starting or Ending Locati
ons beyond about 8.4 GB as: 1024 Cylinders, 255 Heads and 63 Sectors (this means
the values shown in the Partition Table itself will be: 1023, 254 and 63, since
the Cylinder and Head values begin counting from zero). The point here is that
you can no longer compute the capacity of a drive's partitions from its CHS valu
es if any portion of the partition extends beyond 8.4 GB; you can only use the T
otal Number of Sectors to obtain its size in such cases. [See the example Partit
ion Table below.]
NOTE: Various utility programs (such as PowerQuest's PartInNT for Windows) will
display values beyond the standard 1024 cylinders!
( You need to note that this is not what's really inside of your Partition Table
, since it's physically impossible for a 16-byte Partition Table entry to hold a
number larger than 1023 for its cylinder value! There are only 10 bits availabl
e for the Cylinder value, and 11 1111 1111 in binary = 3FF in hex = 1023. ) If
a utility program explains that it's only displaying an interpretation of the da
ta found in the Partition Table, then I'd have no complaints about it. Unfortuna
tely, many utility programs, including all of PowerQuest's utilities and TestDis
k, assume you know the difference; so be aware of this.
However, if you ever see such values being displayed in a Disk Editor (as I reca
ll seeing at least once), that could totally confuse you! It's my opinion that
a Disk editor should always show exactly what's inside of a sector (even when i
t's interpreting the CHS values for you), so you know for sure what data is on t
hat disk!
PQ Utility Users, Note: Various versions of PowerQuest's Partition Magic always
complain about incorrect CHS values for partitions that end or begin after 1024
cylinders! This is very confusing to users of their software! Though we're not e
xactly sure why PQ decided to do this (since their program can easily convert th
e data in the Partition Table into a usable cylinder value), it may be that they
expected BIOS manufacturers to already be making chips that would do this; and
Partition Magic and the BIOS chip should agree on the same cylinder value before
proceeding! (If you find an answer from PQ, let me know.)
After obtaining the data from many different computers with various BIOS chips i
n them, sometimes we've seen a cylinder count of only 1023 instead of 1024 for e
ntries ending or beginning beyond 8.4GB; I'm not quite sure why that should occu
r, but thought you should be aware that some variations still exist in the real
world! As a matter of fact, it has recently been found that some new Linux distr
ibution installation programs under certain settings will alter the Head count i
n a Partition Table to only 16; completely messing up the "geometry" of a drive
for programs that depend upon those values!
Now we'll attempt to examine and account for every sector of a more recent hard

drive that has a capacity of about 20 GB and was partitioned into a number of fi
le systems for three different OSs!
Computing the Capacity of various Partitions on a Disk with many OSs

Example: A 20 GB Hard Disk with Three Different Operating Systems

The BIOS code from a computer with INT 13 Extensions in place, should display th
e size of this drive as: "20492 MB" but this is only an approximate size. To get
the actual capacity (user's area), we need to read the LBA value on the HDD cas
e (which if you recall from above, this Maxtor drive does not list), or use a ut
ility program of some kind.
Data from some Drive ID programs plus some calculations provide us with the foll
owing information for our 20 GB test HDD:
Make and Model:
Maxtor 5T020H2
Firmware Revision:
TAH71DP0
Actual Sector Count:
40,021,632 sectors (LBA).
Surplus Sectors:
3,717 sectors (see below)
Usable Area:
40,017,915 sectors (see below)
Usable Area in bytes:
20,489,172,480 bytes
and in Binary GB:
about 19.0820 GiB
(1 GiB = 1,073,741,824 bytes)
Cylinder Boundaries and Surplus Sectors
Some utilities, such as those that use the data returned by Function 48h of INT
13 (one of the new BIOS Extensions for drives over 8.4 GB), list only 40,017,915
usable sectors for this disk. As a matter of fact, if you open it up with the P
TS-Disk Editor, you'll find at the top of the screen: ... sectors 0 - 40017914.
Y
et WinHex (a commercial disk editor) and some other utilities that are made for
Win 2000/XP, correctly identify this drive as having 40,021,632 sectors! Why is
there a difference? The answer is due to the fact that most OSs are still labor
ing under backwards compatibility issues. One of the old rules being: All user dat
a must fit into partitions that both begin and end at a cylinder boundary! Altou
gh this rule doesn't always waste a whole cylinder of space like that archaic tes
t cylinder (see note here), it can come close to doing so. This general boundary
rule is based on the number of Heads and Sectors that comprise whole cylinders o
n a particular drive; even though such references to CHS values are supposed to
be "outdated" for newer drives!
WinHex states that the last 3,717 sectors of this disk are Surplus Sectors which l
eaves us with the 40,017,915 sectors listed by most utility programs. So, how ca
n we figure that out for some other disk? If you divide the actual Number of Sec
tors (or LBA count listed by a disk manufacturer; 40,021,632 for this one) by 16
,065 sectors per cylinder (that's 255 times 63), the quotient almost never comes
out even! For this disk drive, the integer part is: 2,491 cylinders, and the re
mainder is 3,717 sectors. That remainder (or left-over area) is what WinHex call
s the Surplus Sectors (which are often never used by an OS). Only some of the most
modern OSs may disregard this rule, but when they do, that can cause compatibili
ty problems for a user who boots up to more than one OS on the same drive! For ex
ample, If you partition a new drive using Microsoft's Dynamic Disk (instead of t
he standard Basic Disk), its 2nd, 3rd, etc. partitions are likely to never begin
or end on a cylinder boundary. Some of the latest Linux distributions may act t
he same way if your not careful about deciding how your partitions should be cre
ated.
The following is a layout of our example drive as seen in the Windows 2000 Disk
Management MMC snap-in:
(The yellow highlighting and Linux labels are not in the original view.)
Here we can see that the example disk has been roughly divided into thirds, for

each of the three different OSs installed on it. Since Windows 98 cannot use the
NTFS file system and Linux will not disturb system files on any Microsoft volumes
, it's quite safe to use a Primary Partition (those with the dark blue bar over
them) for each of the three OSs. The Linux OS was divided into three separate ar
eas: 1) the /boot directory, 2) the Swap File (which has its own file-system typ
e: 82h under Linux) and 3) all the other directories off the root (/). The GREEN
border around both the Swap File and Root partitions show that they are Logical
volumes within an Extended Partition!
The following discussion shows views of various Partition Tables as interpreted
by a disk editor. To see how they actually look (as Hexadecimal bytes) on the dr
ive, open this page: Introduction to Partition Tables.
Partition Table Data for the Whole Disk Drive
Let's focus on the Windows 2000 Partition first: It has a Partition Type of 07h,
is bootable, and its Volume Boot Record sector is at CHS 0,1,1 which is Absolute
Sector 63; don't forget that Absolute sectors start counting with a zero (0), a
s do cylinders and heads, whereas the Sector value in a CHS entry begins with a
1. The Partition ends at CHS 877,254,63 or: (878 cylinders x 255 heads x 63 sect
ors) - 1 = Absolute Sector 14,105,069. (You can see that's true by simply subrac
ting 1 from the "Relative Sectors" item in the next partition's entry!) The Leng
th of this partition is clearly shown in the Table as: 14,105,007 sectors. As we
point out on our NTFS 5.0/5.1 Boot Sector page, an NTFS Volume is actually one
sector less than its Partition Length; and it's inside that last sector of the p
artition (Absolute Sector 14,105,006 in this case) that you'll find its Backup B
oot Sector! What's the size in bytes for this partition's volume? 14,105,006 se
ctors x 512 bytes per sector = 7,221,763,072 bytes! Dividing that by 1024 cubed
(or 1,073,741,824 bytes/GiB) equals: about 6.726 GiB; which is the size you'll s
ee in the Windows Disk Management program. [Only rarely does Microsoft use someth
ing other than Binary MB (MiB) and Binary GB (GiB) values.] So, here's a quick s
ummary of this partition's data:
Range: Absolute Sectors 63 - 14,105,069
Length or Total Number of sectors: 14,105,007
Volume size (in NTFS Boot Sector): 14,105,006
Our FAT32 partition has a Partition Type of 0Ch (FAT32 LBA) which means that at
least part of it extends past the 8.4 GB mark. It begins at CHS 878,0,1 (which c
orresponds to Absolute Sector 14,105,070), but the ending CHS values only mean
that its last sector is somewhere beyond the 1024th cylinder! In this case, we m
ust work out its actual location using both the "Relative" and "Total Number" of
Sectors; which is still rather easy to compute for Primary Partitions: 14,105,0
70 + 12,289,725 - 1 = Absolute Sector 26,394,794.
Range: Absolute Sectors 14,105,070 - 26,394,794
Length or Total Number of sectors: 12,289,725
Size in Bytes: 6,292,339,200 bytes (5.86 GiB).
As is often the case, the last Absolute Sector of this partition ends up being o
ne sector less than the number of "Relative Sectors" in the next partition's ent
ry, which means there is no unused space between them.
Most utility programs, however (including PQ's Partition Magic), will calculate
a pseudo set of CHS values having more than 1024 Cylinders. You can figure out t
he number of cylinders that PM would like to use for this partition's Ending Loc
ation by dividing its last Absolute sector plus one (26,394,794 + 1) by 16,065 (
255 times 63); which will equal exactly 1643 Cylinders. So, if a value larger th
an 1023 could actually be contained in a Partition Table, the Ending Location fo
r this partition would be:
1642 254 63 (don't forget that cylinder values inside the table begin countin
g with a zero, so the total number of cylinders is still 1643).

The /boot partition for our Linux (the Partition Type for a Linux Ext2/Ext3 File
System is: 83h) installation begins at Absolute Sector 26,394,795 (or a pseudoCHS of 1643,0,1). This partition is rather small (only 208,845 sectors; or 106,9
28,640 bytes; about 102 MiB); ending at Absolute Sector 26,603,639.
How many bytes are there in a single common HDD cylinder today? (There are: 63 x
255 x 512 = 8,225,280 bytes, or about 7.8 MiB, per cylinder). If you divide the
size of this Linux partition in bytes by that value (106,928,640 / 8,225,280),
you'll get exactly 13 cylinders. Most of the fdisk programs in the Linux (and othe
r OS) worlds simply ask you how many cylinders you want to have for a partition;
so here we have just 13 cylinders compared to the 878 for our NTFS partition, o
r the 765 (6,292,339,200 / 8,225,280) for our FAT32 partition. The summary for o
ur /boot partition is:
Range: Absolute Sectors 26,394,795 - 26,603,639
Length or Total Number of sectors: 208,845
Size in Bytes: 106,928,640 bytes (102 MiB).
The much more interesting (and difficult for some to understand) Extended Partit
ion begins at pseudo-CHS 1656,0,1 (1643 + 13 = 1656). As we pointed out in our I
ntroduction to Partition Tables page, this entry only tells you the total size o
f the Extended Partition (and where it begins) but you know nothing about what's
inside of it until you examine the Extended Partition Table that this entry poi
nts to; which could lead you to many other EBRs inside this partition!!!
Range: Absolute Sectors 26,603,640 - 40,017,914
Length or Total Number of sectors: 13,414,275
Size in Bytes: 6,868,108,800 bytes.
We can, however, use this entry to determine if we have any useable space remain
ing on this hard disk: By adding the length of this partition to its beginning s
ector, we find that it ends at Absolute Sector 40,017,914 which means there is n
o more space left; we already found out (see the Drive ID Table above) that the
total number of sectors we can use to create partitions is: 40,017,915 (plus 3,7
17 surplus sectors).
To learn more about this disk, we must jump to Absolute Sector 26,603,640 (CHS =
1656,0,1) where we'll find the first Extended Partition Table:
You can see from the table above, that there is at least one more Extended Parti
tion Table beyond this one! When you find an Extended Partition Table that has o
nly one entry in it, then you'll know you've finally reached the last partition
table in the whole daisy-chain of Tables.
Check if the page has been updated: http://thestarman.narod.ru/asm/mbr/DiskTerms
2.htm
Start of: http://thestarman.narod.ru/asm/mbr/PartTables.htm
Understanding Partitions and Partition Tables
MBR/EBR Partition Tables
Introduction
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 a
rrived on the scene. By the time PC became a generic term for any personal compu
ter, most of us were using some form of Microsoft's DOS. So, due to the sheer nu
mber of early PCs based on IBM PC DOS (all the "PC-compatibles") and those now r
unning MS-Windows or distributions of Linux, the original PC's basic MBR structur
e (see table below) effectively became the default standard.[1]
The MBR (which is always located on the first sector of a hard disk) contains th
at 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
Offsets (within
(in bytes)
in Decimal
000 - 445
446 - 509
510 - 511
Table 1.

of the Master Boot Record Sector

sector) Length
Description
in Hex
000 - 1BD
446
Code Area
1BE - 1FD
64
Master Partition Table
1FE - 1FF
2
Boot Record Signature

Table 2. This should remove any confusion over what constitutes a valid Boot Rec
ord signature; sometimes called its Magic number, and often expressed as the 16bit hexadecimal Word, 0xAA55 (or: AA55h) for the little-endian[2] PC.
Boot Record Signature
Offset (within sector) Byte Values
( Hexadecimal )
Decimal in Hex
510
1FE
55
511
1FF
AA
Primary Partitions
This standard MBR structure has always contained a Partition Table with four 16byte entries as follows:
The standard 64-byte Primary Partition Table
Offsets (within MBR sector)
Length
(in bytes)
Contents
in Decimal
in Hex
446 - 461
1BE - 1CD
16
Table Entry for Primary Partition # 1
462 - 477
1CE - 1DD
16
Table Entry for Primary Partition # 2
478 - 493
1DE - 1ED
16
Table Entry for Primary Partition # 3
494 - 509
1EE - 1FD
16
Table Entry for Primary Partition # 4
Table 3.
Thus, disks using this standard table can have no more than four Primary partiti
ons, or as we'll describe in the next section, up to three Primary partitions pl
us one Extended partition. These early partitioning tools (called FDISK; short f
or Fixed Disk) even for DOS versions 3.30 and later, were programmed to create o
nly 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 sin
gle Extended primary partition. Under NT-type operating systems, such as Windows
XP, Disk Management will allow three Primary partitions to be created, before r
equiring 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 w
ithin their partition tables:
Structure of a 16-byte Partition Table Entry
Relative Offsets
(within entry) Length
(bytes) Contents
0
1
Boot Indicator (80h = active)
1 - 3 3
Starting CHS values
4
1
Partition-type Descriptor
5 - 7 3
Ending CHS values
8 - 11 4
Starting Sector
12 - 15 4
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 y
ou'll see the entries overlapping each display line. For example, here's a simpl
e (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 represent
ing (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; it
s 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 Ed
itor [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 ma
kes this task much easier now. For the sake of completeness, we'll explain all t
he 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 anyth
ing except 00h in Extended Boot Records. Technically, only the "Active" (bootabl
e) Primary partition is ever supposed to have its 'high bit' set (making that by
te, 80h). Some boot managers might allow logical partitions to be set active, bu
t more likely a boot manager will never use this indicator when doing so.
2. 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 har
d disk. When a sector is beyond that point, the CHS tuples are normally set to t
heir maximum allowed values of 1023, 254, 63; which stand for the 1024th cylinde
r, 255th head and 63rd sector, due to the fact, cylinder and head counts begin a
t zero. These values appear on the disk as the three bytes: FE FF FF (in that or
der).
Note: These bytes are somewhat in the order of Head, Sector and Cylinder, but th
e 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 sect
or on the disk, since its count begins at LBA 0 [4]. The 3-byte Ending CHS value
s 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 value
s to indicate all types of partitions that can exist under the DOS/Basic Disk pa
rtitioning scheme. In this case, 0Bh, indicates a FAT32 file system. See our pag
e here on: Partition Types.
4. Ending Sector in CHS values (3 bytes); 1F 3F 33 in our example above. See: D
ecoding CHS Values.
5. Starting Sector (4 bytes). LBA (Absolute Sector) value. This value uniquely i
dentifies 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 fir
st FFFF FFFFh or 4,294,967,296 sectors, for hard disks up to about 2,199,023,25
5,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 n
umber 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 Lim
its for more details.
When you obtain all 4 bytes of this value (as stored on a little-endian[2] compu

ter), the byte-order must first be reversed. So, for our example above, the: 3F
00 00 00, becomes: 00 00 00 3F. This means that our first (and ony) partition be
gins at Absolute Sector 3Fh, which is also LBA 63 (or the 64th sector on the dis
k). This is the first possible boot sector for any drive having 63 sectors per h
ead/track.
6. 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 parti
tion, and are also stored on disk in little-endian. So the stored bytes, 41 99 0
1 00, become: 00 01 99 41, for a size of: 104,769 sectors, or at 512 bytes/secto
r 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 [pl
us 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 an
d 10-bits, respectively, within the second and third bytes; making them more dif
ficult 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, visual
ly clear:
CHS Bytes
Figure 1. A 3-byte CHS field encodes Cylinder (10-bits), Head (8-bits) and Sect
or (6-bits) values.
How to decode the three CHS bytes: The 8 bits (1111 1110) shown in the "Head" by
te 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 C
HS 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-significna
t bits (10, in this case) from those of the second CHS byte (1011 1111 = BFh), b
ut 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 C
HS 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 (f
or 52 cylinders, 32 heads and 63 sectors). If you had a Partition Table calculat
or, you'd find that's equivalent to LBA sector: 104,831, and LBA 104,831 - LBA 6
2 = 104,768; the same size of the partition in sectors we arrived at when comput
ing it from the "Partition Size" entry above!
NOTE:
For partitions which begin or end beyond the 1024th cylinder, the three CHS byt
es 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 11111 1111) or 3FFh = 1023 for a total of 1
024 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 Tab
le, then each Extended Boot Record (EBR) must also be examined.
It's very important that you understand this: Any Extended partition entry in th
e MBR, only describes what can be thought of as an envelope (or a black box) whi
ch might contain up to 23 Logical drives under the older IBM/Microsoft DOS 3.30 (o
r later) operating systems; and possibly more under Windows 2000/XP or some othe
r 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 Ex
tended partition table (and any others it might link to) inside the Extended par
tition, 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 t
he industry had to come up with a solution that allowed consumers to use all tha
t available disk space; and soon! HDD manufacturers were already advertising muc
h 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 D
OS partition to be created: One of the four possible Primary partitions would be
come 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 sys
tem!
Extended Partition entries usually have Partition Types of either 05h or 0Fh; de
pending 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 Exten
ded partition:
Figure 2.
The only way to figure out just how many Logical Drives there are within an Exte
nded Partition is by jumping to each Extended partition table in the Extended Bo
ot Records until you've found the last EBR table. These EBRs are often 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 pa
rtition tables of each EBR as well as the Master Partition Table!
.
________________________________________
Footnotes
1[Return to Text] Deviations from this standard table structure may exist on som
e 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 spe
cial fifth entry preceding the common 64-byte table (both the free demo of PTS d
isk editor and its successor, the Acronis disk editor, display references to th
is entry; which, coincidentally, conflicts with the location of the Windows NT D
isk signature).
NOTE: Neither the "Dynamic Disk" partitions of Microsoft Windows 2000/XP/2003 (r
ather than the more usual "Basic Disk" partitions), nor the special GUID Partit
ion Table which might be used by a Microsoft Windows Vista install (part of the
new EFI spec) employ the MBR partitioning scheme described on this page. Howeve
r, both of those partitioning schemes do create a "protective" MBR sector with s
pecial entries to keep previous operating systems and partitioning tools from ov
erwriting any data in their GUID partitions.

2[Return to Text] [Return to: Starting Sectors] Any IBM-compatible ("PC") comput
er (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 i
n 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 preced
ing) position than its most-significant byte (or any more significant bytes in-b
etween).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 ari
thmetic problems as soon as the first byte of a large number was accessed; basic
ally the same as we do when adding the least-significant digits of two large num
bers first, carrying any remainder over to the next column, and finally adding t
ogether the most-significant digits last. ( Cf. our note on Microsoft's very con
fusing 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 "larg
er end" before mentioning the "Big-endians," but never wrote, little end. It's e
asy to search the whole book online as proof. Chapters Four and Five (of Part On
e) 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 (se
e his Appendix) he not only used the phrase "little end" (instead of "small end"
), but repeatedly described the Lilliputians as being Little-Endians; though Swi
ft never used that term. For further studies on Endianness, see the Endian FAQ
(which includes Cohen's paper).
3[Return to Text] This tool is still available as a free download from Symantec'
s FTP site: ftp://ftp.symantec.com/public/ . The Windows version of Partition Tab
le Editor is 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 o
f PTS-Disk Editor is also quite nice for quickly checking Extended partitions un
der DOS.
4[Return to Text] To thoroughly understand how CHS tuples correspond to LBA valu
es for the same sectors on a disk, we recommend downloading a handy little Windo
ws utility, PT Calc, which is still available as a free download from Symantec's
FTP site here:
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/ptcalc.zip .
Note: When run, it's window appears in the lower-right hand corner of a 1024x76
8 screen size; the code must be hacked if you wish it to appear in the upper-lef
t corner instead.
Start of: http://thestarman.narod.ru/asm/mbr/PartTables2.htm
An Extended Boot Record
Extended Boot Records are similar in structure to the MBR, but the majority of t
hem will contain nothing more than partition table data and the AA55h Boot Recor
d signature; the first 446 bytes being zero-filled. Exceptions occur in cases wh
ere a programmer decides to use this normally "unused area" for his own code or
data[5] (just as the programmers of many DDOs, such as EZ-drive or Maxblast, had
done in the past. For example, the Linux boot managers, LILO and GRUB also make
use of the so-called "unused area" between the MBR and first possible Volume Bo
ot Record sector).
Structure of an Extended Boot Record (EBR) Sector
Offsets (within sector) Description
Length
(in bytes)

in Decimal
in Hex
000 - 445
000 - 1BD
Normally Unused [5]
446
446 - 509
1BE - 1FD
EBR Partition Table
64
510
1FE
55
Boot Record Signature 2
511
1FF
AA
Table 6.
The usual contents of an Extended Boot Record's partition table:
An EBR Partition Table
Offsets (within sector) Length
(in bytes)
Contents
in Decimal
in Hex
446 - 461
1BE - 1CD
16
Table Entry for this Logical Partition
462 - 477
1CE - 1DD
16
If present, link to next Logical partiti
on
478 - 509
1DE - 1FD
32
Normally Unused
Table 7.
This next diagram shows only one of many possible ways the extended partition in
Figure 2 may actually be divided:
Figure 3.
So, we consider it just as important to copy and store the data contained in any
EBR sectors as you would for the MBR, and to store these copies elsewhere (not
on the same hard disk) and/or write down just the data bytes from each partition
table entry in a notebook. If the OS can no longer read any EBR sector's conten
ts, you'll have a better chance of fixing problems (or recovering your data) kno
wing the contents of these tables! You may use Power Quest's PartInfo[6] program
(which lists all the data from each of the daisy-chained Extended partition tab
les; as well as the MBR) to save the data as a single text file on a floppy disk
ette; along with a binary copy of your MBR sector. But even if you delete the pa
rtition table data or overwrite an MBR sector, you can still recover your partit
ions using TestDisk.
Nesting of Extended partitions only a concept; not reality!
Although some authors have described each logical drive (or partition) within an
Extended partition as being nested inside all preceding logical partitions,[7]
we've never found any concrete examples which support those statements! As a mat
ter of fact, every single partitioning utility we've tested so far,[8] has alway
s produced EBRs with partition table data (and corresponding partitions) which c
ould be displayed the same way you'd find them in a Windows 2000 or XP Disk Manag
ement Snap-in MMC (see Figure 3 above): Each logical drive is independently situ
ated within the single all-encompassing Extended partition; even though data in
the first and each successive EBR links their logical partitions, like pendants
strung together by an invisible chain.
The following comments concern various disk structures and areas in Figure 4 bel
ow (each item is labeled with red numbers in the diagram).
1: The MBR (Master Boot Record) is always located on the first sector of any har
d disk at LBA 0 or CHS (0, 0, 1). Under Microsoft Windows Vista, the first sector
will appear like other MBRs, but it's only there to keep old utility programs fr
om corrupting Vista partitions; which they'd see as unallocated space without th
e old partition table entries. (See: GUID Partition Table for more info on Vista
's actual partition table).
2: The area shown in pink and labeled 2 in our diagram below is sometimes called
a "reserved area" when it includes the MBR sector. It's size is equal to the nu
mber of Sectors per Track (or Head; usually 63 for most drives today), so 63 min
us the MBR sector = 62 sectors. This area is found on all "Basic Disk" partition
ed hard disks, and although it's "unused" by the OS, you may find some very inte
resting data here. When GRUB, or some other boot manager, installs boot code int
o the MBR, it may also fill a dozen or so sectors of this area with part of its

own second stage code. In the past, both DDO (Dynamic Drive Overlay) software an
d boot viruses would fill many of these sectors, and some unruly application may
have stuffed data here as well. A few manfacturers still insert information abo
ut your computer and/or its hard disk into some of these sectors too, so users s
hould carefully examine every sector here, just to know what might be stored in
them.
Areas 3, 4 and 6 are the first (1st), second (2nd) and fourth (4th) Primary part
itions on this disk with data about their locations and sizes normally found in
entries 1, 2 and 4, respectively, of the MBR's Partition Table; unless some OS o
r utility program mixed up their order.
Note: The Microsoft and IBM partitioning tool FDISK doesn't allow for more than on
e Primary partition before requiring an Extended partition be created. The Disk
Management tools of Windows 2000 and later do not have this restriction. Thus, th
e Primary partitions in 4 (2nd) and 6 (4th) could have been created under those
operating systems; just as they can with the fdisk tool under Linux and various
stand-alone utilities.
7: This is just a large area of "Free Space" arbitrarily left unpartitioned by t
he user.[9] Item 5, the third (3rd) Primary partition, happens to be an Extended
partition (which we've expanded in the diagram below to clarify its structure).
Figure 4.
8: EBR. The first EBR (Extended Boot Record) sector within the extended partitio
n.
9: Inter-partition space (also see pink strips following #11 and #14 as well). T
hese areas between all the EBR sectors and their partitions are similar to the "
unused area" between the MBR and the first possible location for a partition on
a Basic Disk; most often equal in size to the number of sectors per head (or SPT
, sectors/track) minus one (the EBR sector); normally 62 sectors.
10: Unused Space. Presumably, this was originally the first logical drive create
d within the extended partition, but at some later time, it was deleted. Upon de
letion, its partition entry was removed from the first EBR, leaving only the lin
k to the next logical partition's EBR sector (#11).
11: EBR for the logical drive partition in #12 and also a pointer to the EBR sec
tor at #14.
12: A valid logical partition within the extended partition; could be unformatte
d or formatted, you need to check its entry for the partition type and the parti
tion itself for valid boot records to actually know for sure.
13: Unused Space. This area could have been part of the original extended partit
ion's second logical drive at creation, in which case some utility program, such
as Partition Magic or GNU Parted, resized (shrunk) the data to the sectors colo
red in blue above (#12). Or, it may have contained an original 3 of 4 logical pa
rtitions that was later deleted (with an EBR sector located somewhere within thi
s area). If that's the case, the utility or OS used to delete the partition also
edited the EBR entry at #11 to jump over the original EBR sector pointing to it
. Some programs will not do that... they would have simply removed the logical d
rive's partition table entry data, and left the pointer to the EBR sector at #14
.
14: EBR. The last EBR within this extended partition.
15: Another valid logical partition or drive within this extended partition.
16: Some unused space at the end of the extended partition. Either the original
logical partition was resized, or the partition's entry data in its EBR sector w
as altered (made smaller) before being formatted, if it ever was (again, you mus
t always check the data within the partition itself to know what if anything is
in there! The EBR entries only tell you what type of partition it's supposed to
be).
Some Real Partition Table Examples

________________________________________
Footnotes
5[Return to Text] One such exception being the IBM Boot Manager [ introduced wit
h OS/2; also used by Power Quest as Partition Magic's first boot manager, which
was later changed under version 4.x. Boot Manager is still being used by some 'd
ie-hard fans of OS/2' under the last version of OS/2 Warp ], which stores boot m
enu data about each logical drive within its EBR as a compact 9-byte entry (at o
ffsets 18Ah-192h). The first byte indicates if that logical drive is included on
the boot menu, and if so, the remaining 8 bytes form the title it displays.
6[Return to Text] Also available from the same FTP site listed in Footnote 3: Pa
rtition Information for the Windows NT/2000/XP operating systems, or PartInfo for
DOS .
7[Return to Text] For example, the archived state (on 5 Jun 2007) of Wikipedia's
article on the File Allocation Table, under the section, Extended partition and
logical drives, contained the statement: "The logical drives were described by
on-disk structures which closely resemble the Master Boot Record (MBR) of the di
sk (which describes the primary partitions), probably to simplify coding, and th
ey were chained/nested in a way analogous to Russian matryoshka dolls." That las
t phrase concerning the Russian dolls (smaller and smaller ones found inside eac
h successive one you open) is far from a correct analogy here! An Extended parti
tion's logical drives are rather like the individual pages of a letter (all unfo
lded) within a large envelope! And after you open the envelope and begin reading
its first page, the second entry in each EBR can be thought of as a heading on
each page which tells us which page number to look for on the next one to be rea
d.
NOTE: Reading articles at Wikipedia can be quite rewarding if you read with caut
ion. For example, ask yourself questions, such as: Where did this material origi
nate? What sources can I find elsewhere to verify this data? And for anything im
portant, you really should read the "discussion" pages, checking for posts about
controversial material (anything the article's editors disagree on; though some
posts are just rants). You might check the edit "history" page, and attempt to
determine if the page has been vandalized (by emotional, personal, sarcastic, le
wd or derogatory remarks; or worse, false information being added, or simply to
see if any of the article has recently been deleted). In short, what you read th
ere is only as good as the people who created and edited its pages; but that's t
rue for anything you see/read on the Net, including my own pages!
The best sources would be those which have undergone scrutiny by many researcher
s looking only for truth and had the ability to test the facts of any statements
made there. Occasionally, a page which seems to be correct, may only be the eff
orts of people with the same bias; all paying homage to the same preconceived no
tion which none have attempted to prove as true or false. ( Note: History, can b
e quite difficult to judge, since few of its 'facts' can ever be tested by exper
iments; only by weighing the accounts of its witnesses, even though some of its
lessons have been repeated on many occasions! )
8[Return to Text] Including the FDISK utilities for both Microsoft MS-DOS 3.3, MS
-DOS 5.0, 6.0, 6.2 AND 6.22, IBM PC-DOS 5.02, Digital Research, Inc. DR-DOS 6.0;
along with the install CDs for Windows 2000 and Windows XP and their Disk Manageme
nt utilities for paritioning a hard disk while those operating systems were runn
ing. Add to this the Linux fdisk utilities of RedHat, Debian, SuSE (now Novell/?
), Fedora Core and others, and Power Quest's (now Symantec/Norton) Partition Mag
ic 8.0. If you have a hard disk with Extended partitions that you'd care to test
, the easiest methods would be to use the Power Quest, Partition Table Editor or
their PartInfo utility. For anyone who wishes to participate in this sort of in
ductive proof, we'll supply other utilities to read info from your drive(s) if t
hey contain partitions created by tools we do not have access to. Proof for a co
mmercial tool (no matter how old) that actually creates nested Extended partitio
ns will receive our immediate attention.
9[Return to Text] Though all DOS partitioning tools leave the last cylinder of e
very disk unpartitioned for use as a test cylinder (which is never used), many W

indows NT partitioning tools now leave a cylinder (usually, 255 heads x 63 secto
rs/head = 16,065 sectors; or at 512 bytes/sector = 8,225,280 bytes) of about 7.8
MiB at the end of a drive in order to have room for converting a Basic Disk to
a Dynamic Disk; should its user so desire.
Start of: http://thestarman.narod.ru/asm/mbr/PartTables3.htm
Real Partition Table Examples
In summary, the layout of a Master Boot Record's sector is as follows:
Offset
Size
Description
------ --------- ---------------------------------000h 446 bytes
Master bootstrap loader code area
(includes the NT Drive S/N if any;
see the Standard, FAT32 and NTFS MBRs for example.)
1BEh
1CEh
1DEh
1EEh
1FEh

16
16
16
16

bytes
bytes
bytes
bytes

2 bytes

Partition
Partition
Partition
Partition

entry
entry
entry
entry

for
for
for
for

partition
partition
partition
partition

1
2
3
4

Signature ID, the WORD: AA55h;

indicates a valid MBR sector.

A 20 GB Hard Drive with Three OSs

Figure 5.
This is a Hex view of just the last 80 bytes of a hard disk's MBR sector as they
might appear in a disk editor. The Partition Table is enclosed within the thin
YELLOW line in the diagram above. Two other items also appear in this diagram: 1
) The thin violet/purple line surrounding the Hex bytes "A8 E1 A8 E1" shows an e
xample of an NT Disk Signature (also used by Win 2000/XP) and: 2) The sector's
Word-sized Signature ID of AA55h; often called its Magic number in older tech do
cumentation.
[ Note: on Intel x86 CPU systems, Hex Words are stored with the Low-byte first a
nd the High-byte last so AA55h appears as: 55 AA in a disk editor ].
In the upper-right corner of the table, you'll see a byte with the value of 80
. This is the first byte in the first Partition entry, and it's followed by the
bytes 01 01 00 . Most HDDs have these bytes, since the first partition is usual
ly the boot partition on most hard disks [ the 80h byte tells the Bootstrap Load
er code (the MBR code) which partition it is supposed to try loading a Boot sect
or from into Memory; only one partition entry (at boot-up) can have the 80h byte
here] and because the next three bytes are the CHS values for the Starting Sect
or of the first partition (CHS 0,1,1 in this case; which corresponds to Absolute
Sector 63 of this disk, where most Boot Records begin).
Until HDDs became larger than 8.4 GB, the Starting and Ending CHS values and the
Total Sector value could be checked against each other; which might help to cor
rect an error for a manual entry in the Table. Example: The Last Sector CHS valu
es (877,254,63) can be used to check the Total number of Sectors by first comput
ing: 878 cylinders x 255 heads x 63 sectors = 14,105,070 sectors (don't forget
that both the Cylinder and Head counts begin with a zero), and then subtracting
the 63 sectors which preceded it to arrive at: 14,105,007 sectors for its Total
size or length. Thus, you can see that they must agree with each other!
Before launching into all the calculations for the rest of this drive's partitio
n table, we need to point out that this isn't the typical layout for a drive cre
ated by a Microsoft OS. Instead of a single Primary partition followed by an Ext
ended partition, this drive has three Primary partitions and then an Extended pa
rtition!

The First 16-byte Entry in our Partition Table

Byte(s)
Offset Value in this
Example Description
Meaning
1BE
80
Bootable? (80h = Yes; 00 = No) YES
1BF - 1C1
01 01 00
Starting Sector ( in CHS )
[ First byte always = Head value ]
0, 1, 1
1C2
07
Partition Type NTFS
1C3 - 1C5
FE FF 6D
Last Sector ( in CHS ):
[ FEh = 254 for Head ]
FF 6D = (1111 1111) (0110 1101)
are regrouped as: [11 1111] [11 0110 1101]
3Fh = Sector 63 and 36Dh = 877 (Cylinder)
877, 254, 63
1C6 - 1C9
3F 00 00 00
Relative Sectors (or Offset )
( 0000003Fh = 63 )
63
1CA - 1CD
AF 39 D7 00
Total Sectors (or Length )
( 00D739AFh = 14,105,007 )
14,105,007
In the table above, you'll find that computing CHS values isn't always very easy
to do! Though the whole first byte for each Starting and Ending CHS entry is al
ways for the Head*, the Cylinder and Sector bytes must be regrouped before you c
an compute them! To compute the Sector value, you must remove the leading two bi
ts of the second (or middle) byte; thus the largest value you can have for a Sec
tor is: 3Fh (__11 1111) = 63. To compute the Cylinder value, the two bits from t
he middle byte become the first two bits of a ten-bit hex number that ends with
the last byte in each CHS entry. So, the largest value you can have for a Cylind
er is: 3FFh (11 1111 1111) = 1023 (in the table, which gives you a count of 1024
cylinders). Since these are the largest values that can be used in any Standard
Partition Table, all CHS values are limited to: 1024 x 255* x 63 = 16,450,560 s
ectors (or 8,422,686,720 bytes); thus the 8.4 GB limit for any BIOS without the
newer INT 13 Extensions (such as Functions 42, 43 and 48 for reading, writing an
d getting drive parameters)!
________________
*For those who missed the note about why we do not use 256 heads, see this: Note
about a 'bug' in MS-DOS.
________________________________________
Therefore, when any part of a partition reaches further than 8.4 GB into a drive
, you lose some redundancy as can be seen in the Last Sector CHS portion of this
entry:
The Second 16-byte Entry in our Partition Table
Byte(s)
Offset Value in this
Example Description
Meaning
1CE
00
Bootable? (80h = Yes; 00 = No) NO
1CF - 1D1
00 C1 6E
Starting Sector ( in CHS )
[ First byte: 00h = 0 for Head value ]
C1 6E = (1100 0001) (0110 1110) in Binary
are regrouped as: [00 0001] [11 0110 1110]
01h = 1 sector and 36Eh = 878 (Cylinder)
878, 0, 1
1D2
0C
Partition Type FAT32
LBA
1D3 - 1D5
FE FF FF
Last Sector ( in CHS ): FE = 254 (Head)
FF FF = (1111 1111) (1111 1111)
are regrouped as: [11 1111] [11 1111 1111]
3Fh = Sector 63 and 3FFh = 1023 (Cylinder)
Beyond
8.4 GB
1D6 - 1D9
EE 39 D7 00
Relative Sectors (or Offset)
( 00D739EEh = 14,105,070 )
14,105,070
1DA - 1DD
BD 86 BB 00
Total Sectors (or Length)

( 00BB86BDh = 12,289,725 )
12,289,725
If the Cylinder value wasn't limited to 1023, then the Last Sector CHS triple's
cylinder value could be computed as follows: 26,394,795 (14,105,070 + 12,289,725
; the same as the Relative Sector Offset in the next entry!) divided by 16,065 (
255 x 63) = 1643 cylinders. So, the CHS would be: 1642,254,63.
And for any full partition that's beyond 8.4 GB, such as the last two entries in
our example Partition Table above, only the values inside of the thin GREEN lin
es can be used to compute both a partition's actual size and location! Note bot
h the Starting Sector and Last Sector items in our example Table's third entry:
The Third 16-byte Entry in our Partition Table
Byte(s)
Offset Value in this
Example Description
Meaning
1DE
00
Bootable? (80h = Yes; 00 = No) NO
1DF - 1E1
FE FF FF
Starting Sector ( in CHS ): FE = 254 (Head)
FF FF = (1111 1111) (1111 1111)
are regrouped as: [11 1111] [11 1111 1111]
3Fh = Sector 63 and 3FFh = 1023 (Cylinder)
Beyond
8.4 GB
1E2
83
Partition Type Linux Ext2
1E3 - 1E5
FE FF FF
Last Sector ( in CHS )
[ Same as for FE FF FF above! ] Beyond
8.4 GB
1E6 - 1E9
AB C0 92 01
Relative Sectors (or Offset)
( 0192C0ABh = 26,394,795 )
26,394,795
1EA - 1ED
CD 2F 03 00
Total Sectors (or Length)
( 00032FCDh = 208,845 ) 208,845
Finally, the fourth entry in our example Table is that of an LBA Extended Partit
ion (type = 0Fh). In the case of any Extended Partition, its Total Sectors (or L
ength) includes all of the Logical partitions that may exist inside of it, wheth
er there's only one or many. Extended Partitions often run all the way to the en
d of a drive's useable sectors, but they don't have to. You should also note tha
t even if all four entries of a Partition Table are being used, that does not ne
cessarily mean there's no empty space left on a drive.
The Fourth 16-byte Entry in our Partition Table
Byte(s)
Offset Value in this
Example Description
Meaning
1EE
00
Bootable? (80h = Yes; 00 = No) NO
1EF - 1F1
FE FF FF
Starting Sector ( in CHS ): FE = 254 (Head)
FF FF = (1111 1111) (1111 1111)
are regrouped as: [11 1111] [11 1111 1111]
3Fh = Sector 63 and 3FFh = 1023 (cylinder)
Beyond
8.4 GB
1F2
0F
Partition Type Extended
( LBA )
1F3 - 1F5
FE FF FF
Last Sector ( in CHS )
[ Same as for FE FF FF above! ] Beyond
8.4 GB
1F6 - 1F9
78 F0 95 01
Relative Sectors (or Offset)
( 0195F078h = 26,603,640 )
26,603,640
1FA - 1FD
83 AF CC 00
Total Sectors (or Length)
( 00CCAF83h = 13,414,275)
13,414,275
Start of: http://thestarman.narod.ru/asm/mbr/DriveOffsets.htm
Drive Offset and Sector Conversions
and

"What's the Sector-Size of Your HDD?"

( Copyright2004 by Daniel B. Sedory )
The default sector-size for almost every single HDD is:
512 bytes per Sector. So that's what was used for each calculation below. Althou
gh most of this page is a Table of HexOffsets and Sector Numbers, you'll also fi
nd some important notes here about disk structures!
Formulas for converting a given Hexadecimal Offset to a Sector Number.
The Table: Hexadecimal OFFSETs and Absolute SECTOR Numbers.
How Many Sectors are there on Your Hard Drive? -- The total number of sectors f
or some ideal-sized HDDs. Almost every drive produced will be a little more or l
ess than these sizes.
________________________________________
FORMULAS for Converting OFFSETs to SECTOR Numbers and Vice Versa
Using the Calculator that comes with any Windows OS, you can easily convert betw
een Hexadecimal and Decimal (when in 'Scientific View'). To find the sector that
a given Hexadecimal (or Decimal) Offset byte resides in use these formulas:
Sector Number = Round Down to the Nearest Integer Number:
[ Hexidecimal Offset / 200 hex ] and convert to Decimal, or:
[ The Decimal Offset / 512 ].
If you're lucky enough to pick the very first byte of a Sector, it will divide e
xactly!
For example, converting the byte at Hex Offset 7C00 to 31,744 (in Decimal) and
dividing it by 512 equals 62 exactly, so 7c00 is the first byte of Absolute Sec
tor 62.
Decimal Offset = (Sector Number x 512) + offset within the sector.
[the "+ offset within the sector " simply means adding 0 through 511 depending u
pon where the byte is in a given 512 byte sector.]
To find the Hexadecimal Offset, either convert the Decimal answer above to Hex,
or use the following:
Hexadecimal Offset = [ Hex conversion of: (Sector Number x 512) ] + Hex offset w
ithin the sector.
For example, (69 x 512 = 35,328)giving us an Offset of: 8A00 Hex for the first
byte of Absolute Sector 69.
The Table
Hexadeciamal O F F S E T S and Absolute S e c t o r s
H e x
O f f s e t s Absolute
S e c t o r
Numbers
Range Hex Offset
of First Byte
in the Sector
000 - 1FF
0 0 0 0
Abs. Sector 0 is the Master Boot Record for all Hard Disk Drives (HDDs).
But for most Floppy Diskettes, this is their OS Boot Record.
(Floppy Diskettes never have a Master Boot Record!)
200 - 3FF
2 0 0 1
Beginning of the 1st FAT copy ( Sectors 1-9 ) for
1440 kb Floppy Diskettes using the FAT12 File System.
400 - 5FF
4 0 0 2
600 - 7FF
6 0 0 3
800 - 9FF
8 0 0 4

A00 - BFF
A 0 0 5
C00 - DFF
C 0 0 6
E00 - FFF
E 0 0 7
1000 - 11FF
1 0 0 0
8
1200 - 13FF
1 2 0 0
9
1400 - 15FF
1 4 0 0
10
Beginning of the 2nd FAT copy ( Sectors 10-18 ) for
1440 kb Floppy Diskettes using the FAT12 File System.
1600 - 17FF
1 6 0 0
11
1800 - 19FF
1 8 0 0
12
1A00 - 1BFF
1 A 0 0
13
1C00 - 1DFF
1 C 0 0
14
1E00 - 1FFF
1 E 0 0
15
2000 - 21FF
2 0 0 0
16
2200 - 23FF
2 2 0 0
17
2400 - 25FF
2 4 0 0
18
2600 - 27FF
2 6 0 0
19
Beginning of the Root Directory ( Sectors 19-32 ) for
1440 kb Floppy Diskettes using the FAT12 File System.
2800 - 29FF
2 8 0 0
20
2A00 - 2BFF
2 A 0 0
21
2C00 - 2DFF
2 C 0 0
22
2E00 - 2FFF
2 E 0 0
23
3000 - 31FF
3 0 0 0
24
3200 - 33FF
3 2 0 0
25
3400 - 35FF
3 4 0 0
26
3600 - 37FF
3 6 0 0
27
3800 - 39FF
3 8 0 0
28
3A00 - 3BFF
3 A 0 0
29
3C00 - 3DFF
3 C 0 0
30
3E00 - 3FFF
3 E 0 0
31
4000 - 41FF
4 0 0 0
32
4200 - 43FF
4 2 0 0
33
Beginning of the Data Area ( Sectors 33 - 2879 ) for
1440 kb Floppy Diskettes using the FAT12 File System.
4400 - 45FF
4 4 0 0
34
4600 - 47FF
4 6 0 0
35
4800 - 49FF
4 8 0 0
36
4A00 - 4BFF
4 A 0 0
37
4C00 - 4DFF
4 C 0 0
38
4E00 - 4FFF
4 E 0 0
39
5000 - 51FF
5 0 0 0
40
5200 - 53FF
5 2 0 0
41
Etc. etc. -- And so on...
7600 - 77FF
7 6 0 0
59
7800 - 79FF
7 8 0 0
60
7A00 - 7BFF
7 A 0 0
61
7C00 - 7DFF
7 C 0 0
62
7E00 - 7FFF
7 E 0 0
63
For most HDDs, this is where the First Partition's Volume Boot Record begins.
NOTE: FAT32 File Systems use three sectors (Abs. Sectors 63-65)
for each Boot Record, and have a Second Copy (at Abs. Sectors 69-71).
NOTE: NTFS File Systems have only one Boot sector, but it's normally
followed by the NTLDR code which usually takes up seven more sectors.
The Second Copy of an NTFS Boot sector is after the end of the volume!
Note: If you view a Hard Disk Logically (i.e., using drive letters, C:, D:, etc.
), then Absolute Sectors 0 through 62 will be "hidden" from view in your disk ed
itor and the first Logical Sector (0) will actually be Absolute Sector 63.
8000 - 81FF
8 0 0 0
64
8200 - 83FF
8 2 0 0
65

8400 - 85FF
8 4 0 0
66
8600 - 87FF
8 6 0 0
67
8800 - 89FF
8 8 0 0
68
8A00 - 8BFF
8 A 0 0
69
8C00 - 8DFF
8 C 0 0
70
8E00 - 8FFF
8 E 0 0
71
9000 - 91FF
9 0 0 0
72
9200 - 93FF
9 2 0 0
73
9400 - 95FF
9 4 0 0
74
9600 - 97FF
9 6 0 0
75
9800 - 99FF
9 8 0 0
76
9A00 - 9BFF
9 A 0 0
77
9C00 - 9DFF
9 C 0 0
78
9E00 - 9FFF
9 E 0 0
79
If an HDD has an NTFS File System in its First Partition, then this is normally
where its $MFT Records begin. The $MFT file record area can be very long.
( NOTE: the exact length in sectors for the $MFT basically depends upon how larg
e the volume is, but there are other factors as well. )
A000 - A1FF
A 0 0 0
80
A200 - A3FF
A 2 0 0
81
Etc. etc.
BA00 - BBFF
B A 0 0
93
BC00 - BDFF
B C 0 0
94
BE00 - BFFF
B E 0 0
95
If an HDD has a FAT32 File System in its First Partition, then this is normally
the first sector of its FAT. The first eight bytes of a FAT32 - FAT will begin w
ith either:
F8 FF FF 0F FF FF FF FF or: F8 FF FF FF FF FF FF FF
or even: F8 FF FF 0F FF FF FF 0F
(unless viewed with a disk editor after booting into a Windows 9x OS; in which c
ase, it will usually begin with the bytes:
F8 FF FF 0F FF FF FF F7 or: F8 FF FF FF FF FF FF F7
or even: F8 FF FF 0F FF FF FF 07 instead. See my page about the "Dirty Shutdown
Flag" for more on why these FAT bytes are changed by the Windows OS!)
( NOTE: the exact length in sectors for each copy of the FAT depends upon how la
rge the partition is and what tool was used to format the drive! However, I've
observed that the same formatting tool may create slightly different FAT lengths
for exactly the same partition! This would require much further study to unders
tand why; any volunteers? )
C000 - C1FF
C 0 0 0
96
C200 - C3FF
C 2 0 0
97
C400 - C5FF
C 4 0 0
98
C600 - C7FF
C 6 0 0
99
C800 - C9FF
C 8 0 0
100
Etc. etc.
FE00 - FFFF
F E 0 0
127
10000 - 101FF 1 0 0 0 0
128
Etc. etc. -- And so on...
7D000 - 7D1FF 7 D 0 0 0
1000
Etc. etc.
FA000 - FA1FF F A 0 0 0
2000
Etc. etc.
FFE00 - FFFFF F F E 0 0
2047
100000 - 1001FF 1 0 0 0 0 0
2048
Etc. etc.
167A00 - 167BFF 1 6 7 A 0 0
2877
167C00 - 167DFF 1 6 7 C 0 0
2878
167E00 - 167FFF 1 6 7 E 0 0
2879
Last Sector of a 1440 kb Floppy Diskette using the FAT12 File System.
Etc. etc. -- And so on...

177000-1771FF 17 7000
3,000
1F4000-1F41FF 1F 4000
4,000
271000-2711FF 27 1000
5,000
4E2000-4E21FF 4E 2000
10,000
FFFE00-FFFFFF FF FE00
32,767
1000000-10001FF 100 0000
32,768
30D4000-30D41FF 30D 4000
100,000
FFFFE00-FFFFFFF FFF FE00
524,287
10000000-100001FF
1000 0000
1E848000-1E8481FF
1E84 8000
FFFFFE00-FFFFFFFF
FFFF FE00
100000000-1000001FF
1 0000 0000
1312D0000-1312D01FF
1 312D 0000
2625A0000-2625A01FF
2 625A 0000
4C4B40000-4C4B401FF
4 C4B4 0000
989680000-9896801FF
9 8968 0000
BEBC20000-BEBC201FF
B EBC2 0000
FFFFFFE00-FFFFFFFFF
F FFFF FE00
1000000000-10000001FF 10 0000 0000
1312D00000-1312D001FF 13 12D0 0000

524,288
1,000,000
8,388,607
8,388,608
10,000,000
20,000,000
40,000,000
80,000,000
100,000,000
134,217,727
134,217,728
160,000,000

How Many Sectors are on Your Hard Drive?

HDDs of exactly
10 GB have:
19,531,250 sectors.
HDDs of exactly
20 GB have:
39,062,500 sectors.
HDDs of exactly
30 GB have:
58,593,750 sectors.
HDDs of exactly
40 GB have:
78,125,000 sectors.
HDDs of exactly
60 GB have: 117,187,500 sectors.
HDDs of exactly
80 GB have: 156,250,000 sectors.
HDDs of exactly 100 GB have: 195,312,500 sectors.
HDDs of exactly 120 GB have: 234,375,000 sectors.
HDDs of exactly 140 GB have: 273,437,500 sectors.
HDDs of exactly 160 GB have: 312,500,000 sectors.
HDDs of exactly 180 GB have: 351,562,500 sectors.
HDDs of exactly 200 GB have: 390,625,000 sectors.
HDDs of exactly 250 GB have: 488,281,250 sectors.
HDDs of exactly 300 GB have: 585,937,500 sectors.
HDDs of exactly 320 GB have: 625,000,000 sectors.
HDDs of exactly 500 GB have: 976,562,500 sectors.
This data depends upon 1 GB = 1,000,000,000 bytes, and 512-byte sectors.
But real hard disks rarely contain the exact values above!
Drive manufacturers always round off to the nearest 10 or even 100 GB.
Thus, our WDC WD800JB-00ETA0 "80 GB" disk actually contains up to
156,301,488 accessible sectors; or, 80.026361856 GB.
However, due to the geometrical constraints of Microsoft's Basic Disk layout (of
255 heads and 63 sectors per head), there are 5,104 surplus sectors at the end
of the disk that cannot be used by the Windows OS. But this still leaves 80.0237
48608 GB that can be used. Microsoft OSs often use a Binary GB of 1,073,741,824
bytes (1024 cubed), so it refers to the same size hard disk as having only about
74.53 GB (which should actually use the new standard abbreviation of GiB instea
d).