All About Disk Geometry and The 1024 Cylinder Limit For Disks.

Large Disk mini-HOWTO
Andries Brouwer, [email protected]
v1.0, 960626

1. The problem

Suppose you have a disk with more than 1024 cylinders. Suppose moreover that
you have an operating system that uses the BIOS. Then you have a problem,
because the usual INT13 BIOS interface to disk I/O uses a 10-bit field for the
cylinder on which the I/O is done, so that cylinders 1024 and past are

Fortunately, Linux does not use the BIOS, so there is no problem.

Well, except for two things:

(1) When you boot your system, Linux isn't running yet and cannot save you from
BIOS problems.This has some consequences for LILO and similar boot loaders.

(2) It is necessary for all operating systems that use one disk to agree on
where the partitions are.In other words, if you use both Linux and, say, DOS on
one disk, then both must interpret the partition table in the same way.This has
some consequences for the Linux kernel and for fdisk.

Below a rather detailed description of all relevant details.Note that I used
kernel version 2.0.8 source as a reference.Other versions may differ a bit.


When the system is booted, the BIOS reads sector 0 (known as the MBR - the
Master Boot Record) from the first disk (or from floppy), and jumps to the code
found there - usually some bootstrap loader.These small bootstrap programs found
there typically have no own disk drivers and use BIOS services.This means that a
Linux kernel can only be booted when it is entirely located within the first
1024 cylinders.

This problem is very easily solved: make sure that the kernel (and perhaps other
files used during bootup, such as LILO map files) are located on a partition
that is entirely contained in the first 1024 cylinders of a disk that the BIOS
can access - probably this means the first or second disk.

Another point is that the boot loader and the BIOS must agree as to the disk
geometry.It may help to give LILO the `linear' option. More details below.

3.Disk geometry and partitions

If you have several operating systems on your disks, then each uses one or more
disk partitions.A disagreement on where these partitions are may have
catastrophic consequences.

The MBR contains a partition table describing where the (primary) partitions
are.There are 4 table entries, for 4 primary partitions, and each looks like

struct partition { char active;/* 0x80: bootable, 0: not bootable */ char
begin[3];/* CHS for first sector */ char type; char end[3];/* CHS for last
sector */ int start;/* 32 bit sector number (counting from 0) */ int length; /*
32 bit number of sectors */ };

(where CHS stands for Cylinder/Head/Sector).

Thus, this information is redundant: the location of a partition is given both
by the 24-bit begin and end fields, and by the 32-bit start and length fields.

Linux only uses the start and length fields, and can therefore handle partitions
of not more than 2^32 sectors, that is, partitions of at most 2 TB.That is two
hundred times larger than the disks available today, so maybe it will be enough
for the next ten years or so.

Unfortunately, the BIOS INT13 call uses CHS coded in three bytes, with 10 bits
for the cylinder number, 8 bits for the head number, and 6 bits for the track
sector number.Possible cylinder numbers are 0-1023, possible head numbers are 0-
255, and possible track sector numbers are 1-63 (yes, sectors on a track are
counted from 1, not 0). With these 24 bits one can address 8455716864 bytes
(7.875 GB), two hundred times larger than the disks available in 1983.

Even more unfortunately, the standard IDE interface allows 256 sectors/track,
65536 cylinders and 16 heads.This in itself allows access to 2^37 = 137438953472
bytes (128 GB), but combined with the BIOS restriction to 63 sectors and 1024
cylinders only 528482304 bytes (504 MB) remain addressable.

This is not enough for present-day disks, and people resort to all kinds of
trickery, both in hardware and in software.

4.Translation and Disk Managers

Nobody is interested in what the `real' geometry of a disk is. Indeed, the
number of sectors per track often is variable - there are more sectors per track
close to the outer rim of the disk - so there is no `real' number of sectors per
track.For the user it is best to regard a disk as just a linear array of sectors
numbered 0, 1, ..., and leave it to the controller to find out where a given
sector lives on the disk.

This linear numbering