You've come to this page because you've asked questions similar to the following:
What's the gen on the 1024 cylinder limit relating to disc drives ? What other size limitations apply ?
This is the Frequently Given Answer for those questions.
|Maximum DASD size
|disc area accessible via the ATA command set
|disc area accessible via the SCSI command set
|12 byte CDBs
|16 byte CDBs
|Maximum DASD size
|disc area visible through INT 13h without INT 13 extensions
|ATA disc area visible through INT 13h without INT 13 extensions
|SCSI disc area visible through INT 13h without INT 13 extensions
|ATA/SCSI disc area visible through INT 13h with INT 13 extensions
One of the most confusing topics for people to get their minds behind are the disc and volume size restrictions that their hardwares, firmwares, and softwares impose upon them. This is a complex area, and often the blame is apportioned wrongly.
Volume sizes are constrained by five things: The APIs and the capabilities of the the firmware, the APIs and the capabilities of the driver and operating system softwares, the disc I/O command hardware interface, the partitioning scheme being employed, and the actual on-disc filesystem format.
The 1024 cylinder limitation is a limitation in the system firmware.
On IBM PCs and compatibles, the system firmware (the BIOS ROM), provides routines for real-mode code to access DASDs (direct access storage devices - i.e. discs, mainly). These routines operate in terms of cylinders, heads, and sectors, and the maximum cylinder number that can be used is 1023.
Real-mode code calls the BIOS by placing parameters in CPU registers and
issuing one of several
INT instructions. For DASD access, the instruction
INT 13h. The cylinder, head, and sector numbers are packed (in a
rather bizarre fashion) into various CPU registers. The sector number
occupies 6 bits, the head number occupies 8 bits, and the cylinder number
occupies 10 bits. With 10 bits, one can represent only the numbers from 0
These INT 13h functions have existed since the original IBM PC.
Any software that uses the system firmware routines to access DASDs will be affected by the 1024 cylinder limitation. Essentially, the software will only be able to "see" the first 1024 cylinders of the disc. We'll come back to the exact ramifications of this later on.
MS-DOS, PC-DOS, DR-DOS/OpenDOS, and FreeDOS all rely directly on the BIOS routines for access to DASDs, so their limitations will affect these operating systems both during boot and whilst running.
Other operating systems rely on the BIOS routines to solve a "chicken and egg" problem; namely that they cannot access discs using their own disc device drivers until those device drivers have been loaded, and they cannot load those device drivers without accessing the disc. So at boot time they use the system firmware routines. Particularly, their boot sectors use the system firmware routines.
The exact extent of the use of the system firmware for disc access, beyond the boot sectors, varies from operating system to operating system.
Windows NT uses the firmware to load NTLDR, NTDETECT.COM, NTOSKRNL.EXE, HAL.DLL, various system files including one of the registry hives, and all of the device drivers that are in the "boot" class.
Linux uses the firmware to load the kernel (and ramdisc) image.
OS/2 Warp uses the firmware to load OS2LDR, OS2KRNL, installable filesystem (IFS) drivers, and base device (ADD) drivers.
Multi-boot utilities such as IBM's Boot Manager and LILO use the firmware to read the partition table, and to read the boot sector of the selected operating system into memory.
All of these things thus have to reside in the BIOS-addressible portion of the boot disc. Because many of them are ordinary disc files, which can live anywhere in their containing volume, this in turn means that the volumes containing the files must be wholly within the BIOS-addressible portion of the boot disc.
The correct way to fix the 1024 cylinder limitation is to provide a new set
of DASD access routines in the system firmware that don't limit the cylinder
number to 10 bits. And indeed this has long since been done. The routines
in question are known as the Phoenix/IBM/Microsoft
extensions (or sometimes as "EDD"), and have been supplied as standard
in most manufacturer's BIOS ROMs since around 1997. The
13h extensions operate in terms of a 64-bit linear block number,
rather than addressing devices using cylinders, heads, and sectors, meaning
that the limit on the BIOS-addressible area of the disc is a
But simply providing the routines is only half of the solution. All of the softwares that uses the BIOS for DASD access need to be updated to use the new extensions throughout. The degree to which this has happened varies from software to software:
DOS-Windows: DOS-Windows 95 OEM Service Release 2
was the first operating system to use the
INT 13h extensions in
all parts of its boot process.
IBM OS/2 and IBM Boot Manager: IBM OS/2 Warp Server for E-business was
the first release of IBM OS/2 to use the
INT 13h extensions
throughout its boot process. IBM OS/2 WSfE also comes bundled with a
revised IBM Boot Manager that also uses the
INT 13h extensions.
This latter has since been incorporated into IBM OS/2 Warp Client, beginning
with version 4.0.14.
Windows NT 2000 was the first release of Windows NT to use the
13h extensions throughout its boot process.
No known release of PC-DOS, DR-DOS/OpenDOS, or FreeDOS uses the
LILO:From version 21.4 onwards, LILO can be
configured (with the
lba32 option) to use the
Once all of an operating system's boot code has been modified to use the INT 13h extensions instead of the original BIOS routines, the 1024 cylinder limitation is completely lifted. There is no reason that any boot file need reside within the first 1024 cylinders of the disc, and boot volumes may cross, or even reside wholly above, the 1024 cylinder line.
The industry first hit the 1024 cylinder limitation when hard disc sizes started to exceed half a GiB. You may have heard of a "504MiB limitation" or perhaps a "528MB limitation". These are just the BIOS 1024 cylinder limitation in disguise. They only apply to ATA DASDs.
The reason that 1024 cylinders equated to 504MiB(528MB) is that the number
of bits for the cylinder, head, and sector numbers provided by the disc
controller chips on ATA discs is not the same as the number of bits used
INT 13h. (
INT 13h has 10 bits for the
cylinder, 8 bits for the head, and 6 bits for the sector, yielding a maximum
possible addressible disc area of 7.87GiB/8.45GB. The disc controller chips
had 16 bits for the cylinder, 8 bits for the sector, but only 4 bits for the
head, yielding a maximum possible addressible disc area of 127.5GiB/136.9GB.)
However, the ATA BIOS hard disc routines simply passed the cylinder, head,
and sector numbers supplied in the INT 13h call straight through to the
device controller chip registers. (In most modern ATA BIOSes one can select
this behaviour by configuring a disc as "NORMAL".) The maximum for each number
was thus the minimum of the two maxima imposed by the
interface and the disc controller chip register interface. This meant that
the maximum possible addressible disc area was actually 504MiB/528.4MB (1024
cylinders multiplied by 63 sectors per track multiplied by 16 heads).
Rather than solve the issue there and then, the industry postponed the problem for several years by stealing an idea from SCSI and modifying it slightly, to produce the concept of "Translation".
The main BIOS in a PC is only capable of controlling ATA devices. Access
to SCSI discs is provided by a BIOS extension, either on the SCSI Host
Adapter card or (on some motherboards with built-in SCSI) contained in the
same ROM as the ATA BIOS. The SCSI BIOS hooks into the
service vector, inserting its own service routine ahead of the service
routine of the ATA BIOS. Code that uses
INT 13h services can
then access SCSI DASDs in the same way as ATA DASDs. (This is why SCSI Host
Adapter cards without BIOS extension ROMs are often referred to by the
misnomer "non-bootable". It's a misnomer because it's not the card that is
booted. It is the disc. It's simply that the BIOS code that reads the boot
sector into memory uses the same
INT 13h routines to access
DASDs as does everything else. Without the
INT 13h hook, it is
impossible to access a SCSI DASD at boot time.)
The idea of translation originated in the SCSI world because SCSI DASDs
are not actually addressed in terms of cylinders, heads, and sectors at the
hardware level. SCSI has always addressed discs as a linear sequence of
blocks, numbered from zero upwards. But the
INT 13h interface
operates in terms of cylinders, heads, and sectors. Therefore, the
INT 13h routines in the SCSI BIOS had to invent a completely
fictitious device geometry, that bore no relation to the actual SCSI device
whatsoever, purely for the sake of the PC system firmware. It would then
use that geometry to translate from the cylinder, head, and sector numbers
used by callers of
INT 13h services into SCSI block numbers
used by SCSI proper.
The exact scheme for inventing the geometry varies from one SCSI BIOS manufacturer to another, but in general it involves picking a fixed number of "heads" and "sectors per track", yielding a fixed "cylinder" size. The total size of the SCSI DASD in blocks is then divided by this cylinder size to yield the number of "cylinders" on the disc. The most common choices are 64 heads and 32 sectors per track, yielding a handy cylinder size of exactly 1MiB; and 256 heads and 63 sectors per track, yielding a cylinder size of 7.87MiB. Some SCSI BIOSes even allow one to choose from one of several schemes, via an option in the SCSI BIOS' SETUP utility. Adaptec SCSI BIOSes call this option "Extended BIOS translation for drives > 1Gbyte", for example, which switches between 64 heads/32 sectors and 256 heads/63 sectors. Most SCSI BIOSes provide at least these two choices.
ATA BIOSes stole the idea of fictitious geometries from SCSI, and divorced
the disc geometry as seen at the
INT 13h interface from the disc geometry
as used when talking to the ATA disc controller chip itself. The geometry
used to talk to the disc controller chip became the "logical geometry",
and the geometry used by callers of the
INT 13h routines became the
"translated geometry". (The term "physical geometry" meant the geometry
used in the disc unit itself. Ironically, the geometry used to talk to the
disc controller chip was already divorced from the actual
physical geometry of ATA DASDs.)
There are two major schemes used for creating the translated geometry from
the logical geometry. Both allow the full 8 bits of the head number, as
supplied at the
INT 13h interface, to be used, instead of only
4 bits. This meant that the maximum BIOS-addressable portion of the disc
rose from 504MiB/528MB to 7.87GiB/8.45GB, allowing the industry to postpone
the onset of the 1024 cylinder problem.
The first scheme simply doubles the number of heads and halves the number of cylinders until the number of cylinders is less than 1024 (or the number of heads is greater than 127). In most modern ATA BIOSes this is known as "LARGE".
The second scheme operates more like the fictional geometry creation of SCSI BIOSes in that it fixes the number of heads at 256 and the number of sectors per track at 63, and divides the total number of blocks on the disc by 16128 to obtain the number of cylinders. In most modern ATA BIOSes this is known as "LBA". Since it relies on logical block addressing commands that ATA disc controller chips are not required to provide, it is not usable with all ATA DASDs.
Translation was only ever a bodge, however, that didn't fix the actual problem. All that it gave users were problems with moving discs between machines whose ATA BIOS manufacturers had decided to use different translation schemes. The industry simply hit the 1024 cylinder problem all over again, some years later, when disc sizes started to exceed 7.87GiB.
|Maximum DASD size
|OS/2 Warp base device drivers
|OS/2 Warp direct DASD access via
Once booting is complete, a protected mode operating system relies solely
on its own protected mode device drivers for hard disc access. So any
limitations are imposed by software and are unrelated to the BIOS.
Fortunately, no protected mode operating system imposes the same daft 10 bit
limitations as the BIOS
INT 13h interface does. Indeed, some
of the limitations are exceedingly generous.
OS/2 Warp may have a 16-bit device driver model invented in 1987, but that driver model uses a full 16 bits for cylinder, head, and sector numbers in I/O request packets. OS/2 base device drivers can thus address discs of up to 128PiB/144.1PB . (You may not have seen those abbreviations used before in discussions of disc sizes. They stand for "petabinary-", denoting 2 to the power 50, and "peta-", denoting 10 to the power 15.)
This is well into the realms of silly numbers here, as no disc hardware supports discs that large. It is presented simply in order to point out that the base device drivers under OS/2 impose no practical limitations on disc sizes.
There is no 1024 cylinder limitation for native OS/2 softwares.
Direct access to physical discs from application mode code is via the
IOCTL_PHYSICALDISK category of I/O Control functions. These
TRACKLAYOUT data structure. Once again, this is a
16-bit data structure invented in 1987. But once again, this uses the
full 16 bits for cylinder, head, and sector numbers. Applications can
thus also address, in direct I/O operations, discs of up to
Ironically, OS/2's fdisk tries to be a good neighbour, and
refuses to create FAT partitions that cross or lie wholly beyond the 1024
cylinder line. It does this on the grounds that whereas HPFS partitions are
not visible to DOS, FAT partitions are, and because — as mentioned above —
no flavour of DOS uses the
INT 13h extensions, all FAT
partitions must be within the first 1024 cylinders for DOS not to become
confused when trying to access their contents. In my opinion, this
restriction should be eliminated. OS/2 has no problem with FAT partitions
wherever on the disc they may be, and this is, after all,
OS/2's fdisk. It should be able to create any
partition that OS/2 itself would be happy with. Being a good neighbour to
DOS is all very well, but not at the expense of disallowing things that OS/2
itself is perfectly happy with.
Microsoft's scandisk (which is only capable of deal with volumes formatted as FAT) allocates a block of virtual memory and reads the entire FAT into it. This limits the overall size of a FAT to 16MiB. What this implies depends from the FAT width.
For FAT32, this limits the overall number of clusters in the volume to 4,177,920, which in turn limits the volume size. For a 32KiB cluster size, this limits the volume to 127.53 GiB.
See Microsoft's Knowledgebase article #184006.
|Filesystem format and allocation unit (cluster) size
|Maximum volume size
|Software and allocation unit (cluster) size
|Maximum volume size
|OS/2 Warp HPFS filesystem driver
|Windows NT NTFS filesystem driver
Filesystem layouts impose some limitations of their own on the size of volumes.
All FAT filesystem types use 8 bits to store the number of sectors per cluster, meaning that clusters can be up to 128KiB in size. (This is ridiculously large, of course. The disc cache would be reading and writing 256 sectors at a time, even for 1 byte files. Performance would go through the floor.) In practice, however, operating systems try to be compatible with MS-DOS, which is unable to deal with cluster sizes greater than 32KiB because of internal 16-bit limitations. The optimum cluster size for use with Windows NT, because of the way that its cache manager works, is 4KiB.
FAT12 uses 12 bits to store cluster numbers, FAT16 uses 16 bits, and FAT32 uses 24 bits. Each is thus limited as to the number of clusters in a volume. Because several cluster number values are reserved as special marker values, the maximum number of clusters is slightly less than the maxima that the bit widths alone imply. The volume size limits are thus constrained by a combination of the bit widths and the number of sectors in a cluster.
The HPFS filesystem has no notion of clusters. HPFS works solely in terms of disc sectors, and uses 32-bit numbers to store sector addresses in all of its structures, just like the MBR partition table scheme and the SCSI command set. With the usual 512 byte sectors, this makes the maximum size of an HPFS volume 2TiB/2.20TB.
Even such a large volume will only use 1KiB (2 sectors) to store a 1 byte file: one sector for the data and one sector for the file's f-node. Contrast this with a 2TiB FAT32 volume where a 1 byte file requires 128KiB of disc space.
The HPFS filesystem driver in OS/2 Warp masks off the top 5 bits of a sector address, which reduces the maximum volume size to a "mere" 64GiB. This is, however, a coding flaw in one particular HPFS driver, which can (and in my opinion should) be fixed. The actual filesystem structure on disc doesn't share this limitation.
Like HPFS, the HPFS2 filesystem has no notion of clusters. HPFS2 works solely in terms of disc sectors. Unlike HPFS, HPFS2 uses 64-bit numbers to store sector addresses in all of its structures, just like the partition table and the SCSI command set. With the usual 512 byte sectors, this makes the maximum size of an HPFS2 volume 8.0ZiB/9.22ZB.
As with HPFS, even such a large volume will only use 1KiB (2 sectors) to store a 1 byte file with HPFS2: one sector for the file sector data themselves and one sector for the file's FileNode.
NTFS allocates space in terms of clusters, which in theory may range from 0.5KiB to 128KiB in size, just as for FAT. NTFS uses 64-bit fields to store cluster numbers. So the theoretical maximum size of an NTFS volume, with the largest possible cluster size (which is, as for FAT, ridiculously large and inefficient), is 2YiB.
In practice, the maximum size of an NTFS volume is much lower, because Microsoft's NTFS drivers in Windows NT use 32-bit numbers for cluster numbers, not 64-bit numbers, and only support cluster sizes up to 64KiB. This reduces the practical maximum size of an NTFS volume to 256TiB/281.5TB. As with HPFS, this is a coding flaw in one particular NTFS driver, not a limitation of the filesystem structure on disc.
From Windows NT version 3.51 onwards, the maximum cluster size (when new volumes are high level formatted) is further reduced to 4KiB, both because this is an efficient size for paging and because the NTFS file compression mechanism places this limit on cluster sizes, reducing the practical maximum size of an NTFS volume yet further to 16TiB/17.6TB.
|Maximum DASD/partition size
Partition table schemes impose their own limits on the sizes of both DASDs and
volumes. The MBR, BSD disklabel, and EFI partition table schemes store partition
<start,length> tuples. The bit widths of the
length fields constrain the sizes of individual partitions; and the bit widths
of the start fields constrain the sizes of the areas of the disc that the
partition table scheme can cover.
Most partition table schemes use the same bit widths for both the start and the length fields of a tuple, and thus the maximum partition size and the maximum partitionable area of the disc are the same. The MBR partition table scheme uses 32-bit words for both fields, as does the original version of the BSD disklabel partitioning scheme. The revised version of the BSD disklabel partitioning scheme uses 48-bit words. The EFI partition table scheme uses 64-bit words.