If you want to see the list of sections in this document, to more easily navigate to a specific section, enable the navigation bar support in your WWW browser.
You've come to this page because you've asked a question similar to the following:
What is a BIOS parameter block (BPB)?
This is the Frequently Given Answer to such questions.
A BIOS parameter block is a variant record embedded within the boot block (block zero) of a disc volume. It describes the volume's filesystem format, and provides various pieces of (filesystem-dependent) information about the size and layout of some of the on-disc data structures for that filesystem.
The "BIOS" in "BIOS parameter block" is not a reference to what is
nowadays commonly referred to as "the BIOS": the machine's firmware. PC
firmware is wholly ignorant of BIOS parameter blocks. The name has its
origins in the design of MS/PC-DOS version 2.0 (which in turn was derived from
the design of CP/M) whereby the operating system was divided into an upper
half, dealing with system calls and the abstractions of files and directories,
and a lower half, dealing with device drivers and the nitty gritty of physical
DASD access. The upper half was the BDOS, the "Basic Disc Operating System",
and the lower half the BIOS, the "Basic Input/Output System". (These two
parts of MS/PC-DOS are held in two separate image files on disc, in all
versions of MS/PC-DOS up to version 5.x. In PC-DOS, and in DR-DOS, they are
named "IBMDOS.COM" and "IBMBIO.COM", respectively,
the file names directly reflecting the names of the operating system
components.) The "BIOS" in "BIOS parameter block" is a reference to the lower
half of the MS/PC/DR-DOS operating systems.
BPBs originated with MS/PC-DOS version 2.0, as a replacement for the mechanism that MS-DOS version 1.0 had theretofore used to identify volume sizes, the media description byte in the first byte of the first File Allocation Table. They were required because with the advent of MS/PC-DOS version 2.0 the media description byte was insufficient for the task of describing a disc volume's format.
As subsequent versions of MS/PC-DOS, and other operating systems, required additional capabilities (for larger volumes and additional filesystem formats), various extensions were added and changes were made. Thus BPBs are (in database terminology) variant records. Signature fields are used to determine which variant is being employed.
Unfortunately, due to a very poor piece of design on Microsoft's part, the signature fields of the various types of BPB are only 1 byte wide and are not in the same place across all different BPB types. So the signature byte in one kind of BPB is an entirely different field in another kind of BPB. This has the unfortunate consequence that checking the signature bytes by themselves is not sufficient. A valid signature byte for one kind of BPB could exist simply as a byproduct of another kind of BPB just happening to have the right values in its fields. (Design tip: For variant records, always locate your signature fields at the same byte offset into the record.)
Some documentation describes three of the BPB variants as "FAT12 BPB", "FAT16 BPB", and "FAT32 BPB". This nomenclature is incorrect. The extensions to the original BPB structure are tied to operating system versions, not to FAT widths. Indeed, given that BPBs are employed by filesystem formats other than FAT, the BPB types are not in fact related to FAT at all, and the aforementioned nomenclature is highly misleading.
Because they were originally designed for use on IBM PC compatible machines with Intel CPUs, all of the (integer) fields in BPBs are little-endian.
| offset from start of boot block | width in octets | description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0B | 2 |
size of a sector, in bytes This directly corresponds to the sector size with which the physical disc medium has been low-level formatted. For the overwhelming majority of disc units nowadays, which are low-level formatted by the manufacturer (and often impossible for the consumer to low-level format) this is 512 bytes. |
||||||||||||
| 0x0D | 1 |
number of sectors in an allocation unit Filesystem formats such as FAT and NTFS allocate disc space in groups of sectors, termed clusters. Filesystem formats such as HPFS allocate disc space one sector at a time. For the latter group of filesystem formats, this field should be set to 1 when creating a BPB, and ignored when reading one. The number of sectors in an allocation unit (for the former group of filesystem formats) should be non-zero and an integral power of two. Some operating systems refuse to recognize BPBs if this field contains zero or a number that is not a power of 2. It is not a requirement that the number of sectors per allocation unit be a power of 2, however, and several filesystem drivers are perfectly capable of handling such allocation unit sizes. Thus the recommended maximum value for this field is 128, which (with a 512-byte sector size) results in an allocation unit size of 64KiB. 32-bit operating systems have no trouble with 64KiB allocation units. Most 16-bit operating systems cannot cope with allocation units larger than 32KiB, however, with the consequence that the maximum value for this field (when accomodating such operating systems) is 64. |
||||||||||||
| 0x0E | 2 |
number of "reserved" sectors This is the number of sectors in the area at the start of the volume that is reserved for operating system boot code, the boot area. Since the BPB resides within the volume's boot block, there is at least 1 sector in the boot area and this must be 1 or greater. If this field contains zero, a default, filesystem-format-specific, value is implied. For 12-bit and 16-bit FAT, where the root directory has a fixed size and is in a fixed position, the boot code can fit into a single block, and only the 1 sector is required. The default value is thus 1. For 32-bit FAT, which has variable-length and variable-position root directories, the boot code is too large to fit into a single sector. When creating 32-bit FAT volumes, Microsoft's tools reserve 32 sectors for the boot area, although the actual boot code is not in fact that large. The default value is thus 32. For HPFS and NTFS, which have complex on-disc structures, the boot code is too large to fit into a single sector. For both formats, the default value is 16. However, Microsoft's NTFS drivers will (for no really good reason) fail to mount an NTFS volume if this field actually contains the value 16, or indeed any non-zero value. It is recommended that the boot area size be an integral multiple of the cluster size. This is because in some filesystem formats (e.g. FAT) cluster zero is the first cluster following the boot area and the boot area does not have cluster numbers, whereas in other filesystem formats (e.g. NTFS) cluster zero is the first cluster in the volume and the boot area has cluster numbers. If the boot area is an integral multiple of the cluster size, cluster boundaries on both kinds of filesystem format will be aligned, making conversion between two such formats simpler. If the boot area is not an integral multiple of the cluster size, cluster boundaries on both kinds of filesystem format will not be aligned, and conversion has to employ a smaller cluster size for conversion between two such formats. |
||||||||||||
| 0x10 | 1 |
number of File Allocation Tables In the FAT filesystem format, there are, by convention, 2 copies of the File Allocation Table. In theory, there could be more. In practice, this is almost never the case, as the benefit of further copies is minimal. If this field is zero and yet the filesystem type is FAT, then the volume has been damaged or incorrectly formatted. Other filesystem formats do not contain FATs. For those formats, this field should be set to zero when creating a BPB, and should be expected to contain zero in normal operation. However, it should not be required to be zero. (When volumes are being converted from FAT to NTFS, for example, the conversion process arranges for the volume to contain the data structures for both filesystem formats simultaneously, and this field will be non-zero.) |
||||||||||||
| 0x11 | 2 |
number of 32-byte records in the fixed-size/fixed-position root directory For HPFS, NTFS, and EXT2, which have variable-length and variable-position root directories and where the root directory is not a primary filesystem structure (and a superblock or a master file table is), this field should be set to zero when creating a BPB and ignored when reading one. For FAT:
For vanilla 12-bit and 16-bit FAT, the root directory has a fixed size and is in a fixed position, and this field must be non-zero. For vanilla 32-bit FAT, the root directory has a variable size and is in a variable position, and this field must be zero. There is an extension to the FAT filesystem format where if this field contains the value zero, the root directory is considered to be variable-length and variable-position, and if this field contains a non-zero value, the root directory is considered to be fixed-length and fixed-position, irrespective of FAT width. This is not supported by the FAT filesystem drivers in IBM/Microsoft operating systems or in Linux, though. |
||||||||||||
| 0x13 | 2 |
total number of sectors in volume This is the total number of sectors, as seen by the tool that high-level formatted the volume, in the volume. (It need not correspond to the size of the disc slice containing the volume, although in practical terms it should be less than or equal to that size for normal operation to occur.) It comprises the entire volume, including the boot area. When writing a BPB: If the number of sectors in the volume is small enough to be stored as a 16-bit number, write it in this field. Otherwise write 0 in this field. When reading a BPB: This field is definitive if it contains a non-zero value, or if there is no other, wider, field. Microsoft's NTFS filesystem driver does not support NTFS volumes that contain 65535 or fewer sectors. It therefore refuses to mount volumes where this field contains a non-zero value. This is not a limitation that is inherent in NTFS itself, however. |
||||||||||||
| 0x15 | 1 |
media description byte This is the same media description byte as MS/PC-DOS version 1.0 stored in the first byte of the first File Allocation Table. The media description byte was obsoleted by BPBs, which contain more extensive information, capable of describing fixed disc devices. This field has little practical use. However, a few operating systems will check the MDB field when they are reading BPBs, and ignore the BPB if the MDB field does not contain a "sane" value. This check is not recommended for new softwares, which should simply set this field to some reasonable value when creating a BPB, and ignore it when reading BPBs. |
||||||||||||
| 0x16 | 2 |
sectors per FAT In the FAT filesystem format, this is the size of the FAT as determined by the tool that high-level formatted the volume. High level format utilities determine the FAT size based upon the size of the volume (as they see it) and the cluster size, which together determine the number of clusters in the volume and hence the width of a FAT entry and the number of sectors required to hold the table. Other filesystem formats do not contain FATs. For those formats, this field should be set to zero when creating a BPB, and should be expected to contain zero in normal operation. However, it should not be required to be zero. (When volumes are being converted from FAT to NTFS, for example, the conversion process arranges for the volume to contain the data structures for both filesystem formats simultaneously, and this field will be non-zero.) When writing a BPB: If the number of sectors per FAT is small enough to be stored as a 16-bit number, write it in this field. Otherwise write 0 in this field. When reading a BPB: This field is definitive if it contains a non-zero value, or if there is no other, wider, field. |
With MS/PC-DOS version 3.0 came better support for multiple primary partitions on hard discs. With it thus came an extension to the BPB structure to allow boot code to be informed of the disc-relative block number of block zero of the volume.
| offset from start of boot block | width in octets | description |
|---|---|---|
| 0x0B | 13 |
MS/PC-DOS version 2.0 BPB |
| 0x18 | 2 |
sectors per track This is the logical disc geometry, as it appeared to the tool that high-level formatted the volume. This field is used by the boot code in the remainder of the boot block to translate logical block addresses into Cylinder/Head/Sector addresses, on systems where the machine firmware does not support the EDD firmware extensions. |
| 0x1A | 2 |
number of heads This is the logical disc geometry, as it appeared to the tool that high-level formatted the volume. This field is used by boot code in the remainder of the boot block to translate logical block addresses into Cylinder/Head/Sector addresses, on systems where the machine firmware does not support the EDD firmware extensions. |
| 0x1C | 2 |
number of "hidden" sectors This is the number of sectors between the actual start of the physical disc and the start of the volume. In other words, it is the disc-relative block number of volume-relative block zero. This field is used by boot code in the remainder of the boot block when it needs to call the machine firmware in order to perform I/O from and to the boot volume. The value in this field is added to the volume-relative block number to yield the disc-relative block number. |
With MS/PC-DOS version 3.2 came support for disc volumes located within an extended partition. With it thus came changes to the BPB structure to accommodate "logical drives in an extended partition".
| offset from start of boot block | width in octets | description |
|---|---|---|
| 0x0B | 19 |
MS/PC-DOS version 3.0 BPB |
| 0x1E | 2 |
total number of sectors in the partition This is the sum of the total number of sectors field and the "hidden" sectors field. It is redundant with both those fields and the partition length information held in the partition table proper. As such, it was dropped from later versions of MS/PC-DOS. |
In various OEM versions of DOS after version 3.2, such as Compaq DOS version 3.31, the BPB was changed to accommodate disc sizes larger than 32MiB. (With a conventional 512-byte sector size, a version 3.2 BPB could only describe volumes that were smaller than 32MiB.)
Although there never was such a version, this is known as the MS/PC-DOS version 3.4 BPB, and has become the "standard" BPB layout.
Most modern operating systems assume this layout in the absence of BPB signatures to indicate one of the later BPB versions. However, this is not, strictly, a legitimate assumption. Whilst it is backward compatible with the MS/PC-DOS version 2.0 BPB, this layout is not backward compatible with the MS/PC-DOS versions 3.0 and 3.2 BPBs.
This is the first version of the BIOS Parameter Block that was formally
documented by IBM/Microsoft. An in-memory version 3.4 BPB structure, a
superset of the on-disc version 3.4 BPB structure, is documented in the
OS/2 Developers' Toolkit as the
BIOSPARAMETERBLOCK structure.
| offset from start of boot block | width in octets | description |
|---|---|---|
| 0x0B | 13 |
MS/PC-DOS version 2.0 BPB |
| 0x18 | 2 |
sectors per track Same as for the MS/PC-DOS version 3.0 BPB |
| 0x1A | 2 |
number of heads Same as for the MS/PC-DOS version 3.0 BPB |
| 0x1C | 4 |
number of "hidden" sectors This is the same as the field at offset 0x1C in the MS/PC-DOS version 3.0 BPB, except that this field is now 32 bits wide, not 16 bits. Microsoft's NTFS documentation states that this field is "not used or checked by NTFS". That statement is false. Its Volume Boot Record boot code for NTFS uses this field in the same manner, described here, as the VBR boot code for all other filesystem formats and operating systems do. Converting between volume-relative and disc-relative addresses is something that all VBR boot code has to do. It is not something that can be avoided, Microsoft's spurious NTFS technical documentation notwithstanding. Because of the way that MS/PC/DR-DOS device drivers operate, MS/PC/DR-DOS volume format utilities (and thus all other format utilities that emulate them) set this value incorrectly for secondary partitions located within an "extended" partition (in the MBR partitioning scheme). Thus, without external assistance, the boot code in the remainder of the boot block will fail if a secondary partition is booted directly. Boot manager programs that allow booting from secondary partitions render this external assistance by up fixing this field as they read the volume boot sector in, adding to its value the block address of the secondary MBR that describes the partition. Note that the way that the boot code uses this field, to convert volume-relative block numbers into disc-relative block numbers, has the consequence that all bootable partitions that use BPBs and VBRs must reside within the first 2TiB of the disc. This limitation applies irrespective of filesystem format and even if a disc is partitioned with the EFI GUID partitioning scheme. If the volume resides beyond the first 2TiB of the disc, the offset used to convert between volume-relative and disc-relative block numbers will be greater than this field can hold, and VBR boot code will simply fail to operate correctly, because it will read the wrong areas of the disc. The only way to remove this limitation is to employ firmware that doesn't involve Volume Boot Records in the boot process, such as EFI firmware or ARC firmware. With such firmwares, booting is performed by reading a boot loader directly from a file; VBRs are ignored; the firmware understands disc partitions; and the firmware services for reading sectors from volumes thus themselves apply the correct offsets for converting from volume-relative block addresses to disc-relative block addresses, without need for the boot loader to do so. |
| 0x20 | 4 |
total number of sectors in the volume This is the same as the total number of sectors field in an MS/PC-DOS version 2.0 BPB, except that it is a 32-bit wide field. When writing a BPB: If the number of sectors in the volume is small enough to be stored as a 32-bit number, write it in this field. Otherwise write 0 in this field. When reading a BPB: If the field at offset 0x13 contains a non-zero value, that field is definitive and this field is ignored. Otherwise this field is definitive if it contains a non-zero value, or if there is no other, wider, field. |
MS/PC-DOS version 4.0 was contemporary with OS/2 version 1.0. OS/2 supported multiple filesystem types, media change detection using a volume label and serial number, and booting from other than the first disc unit. Extensions to the BPB structure were added in order to incorporate these. They were added to both OS/2 and MS/PC-DOS.
A common misconception is that this BPB version is specific to 16-bit FAT, and that 12-bit FAT uses older BPB versions. That is not true. This BPB version is, after all, used by OS/2 for HPFS volumes, and its very raison d'être is to enable support for different filesystem formats within a single partition type. 12-bit FAT volumes that have been formatted by PC/MS-DOS version 4.0 or later, or by OS/2, also use this BPB version. It was introduced across the board for all filesystem formats. BPB versions are tied to operating system versions, not to FAT widths.
| offset from start of boot block | width in octets | description | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0x0B | 25 |
MS/PC-DOS version 3.4 BPB |
||||||||
| 0x24 | 1 |
Disc unit number This is the disc unit number that is used when performing I/O using the DASD access functions supplied by the machine's firmware. This field is (sometimes) used by boot code in the remainder of the boot block when it needs to call the machine firmware in order to perform I/O from and to the boot volume. Volume format utilities set this to 0x00 for removable discs and 0x80 for fixed discs. This is, of course, wrong when the disc is not, in fact, the first fixed/removable disc in the system. Thus boot manager programs that allow booting from other than the first fixed/removable discs in the system will fix up this field as they read the volume boot sector in, substituting the actual firmware disc unit number. In practice, this field is not suitable for use by boot code, because it is not in the same location in all BPB versions. Boot code that assumes a particular location for this field and reads the firmware disc unit number from it is locking itself into a particular BPB version. Doing so is completely unnecessary, given that the PC firmware passes the correct disc unit number to boot code in the DL register on entry. Boot code should stash the supplied value of the DL register in some suitable memory location (not this one, because assuming that one can write the disc unit number here is as bad as assuming that one can read the disc unit number from here) and use that when performing I/O using machine firmware calls. Given that operating systems either know the firmware unit number before reading a BPB (since they have to know the unit number in order to read the BPB in from disc in the first place) or do not use the machine firmware to perform I/O, and thus that neither operating systems nor boot code need this field, this field thus has no practical use. Its value should be ignored. |
||||||||
| 0x25 | 1 |
"chkdsk" flags Originally reserved for future use, this field was turned into a set of flags by Windows NT, which employs these flags both on FAT and on NTFS volumes. Because these flags are generic, they can be employed with most filesystem formats. Note, however, that the HPFS and EXT2 filesystem formats have their own "chkdsk" flags, incorporating more information than this field does, in their superblocks/spareblocks. This field is also used by boot managers to communicate the letter assignment of the boot volume to OS/2. The boot managers set bit 7 and set bits 0–6 to the drive letter, where 'C' is 0, 'D' is 1, 'E' is 2, and so forth. The OS/2 kernel inspects this field in the in-memory BPB passed to OS2LDR by the filesystem-dependent boot loader. If bit 7 is set to 1, then it subtracts 128 from the value of the field, adds 'C', and uses that as the drive letter. This does not affect the value of the field on disc, which can still contain "chkdsk" flags. |
||||||||
| 0x26 | 1 |
Signature byte The values 40 (0x28) and 41 (0x29) in this field indicate that this is an MS/PC-DOS version 4.0 BPB. Other values indicate other BPB variants, such as the Windows NT BPB. (Note, however, the botch that was made when the MS-DOS 7.0 BPB was defined.) |
||||||||
| 0x27 | 4 |
Volume serial number The volume serial number is assigned by the tool that formats the volume in such a way that, on a single-tasking operating system, no two volumes formatted by a single system will have identical volume serial numbers. MS/PC/DR-DOS tools calculate the volume serial number from the current date and time at the time of formatting, using the following formulae:
OS/2 and Windows NT tools use the same formulae. However, because they are multitasking operating systems, capable of formatting multiple volumes simultaneously, uniqueness is not guaranteed within a single system. Volume duplication utilities are required to not copy volume serial numbers from source to target volumes. Modern volume duplication tools on IBM/Microsoft operating systems in general obey this stricture, whereas tools on Unix and Linux do not. The intent of the volume serial number is to provide a mechanism for medium change detection on removable non-partitioned discs. The operating system compares its in-memory copy of the serial number with the number on the disc, at various points, and if the two do not match it considers the volume to have changed. However, given the deficiencies of Unix and Linux volume duplication tools, and given the fact that multitasking operating systems can in theory format two removable discs at the same time (thereby giving them both the same volume serial number), volume serial numbers are an imperfect mechanism for medium change detection. |
||||||||
| 0x2B | 11 |
Volume label |
||||||||
| 0x36 | 8 |
Filesystem type Filesystem types are space-padded, and comprise uppercase-only US-ASCII alphanumeric characters. All of the bytes in the field are significant. |
||||||||
| 0x3E | 8 |
Reserved for future use Set to 0 when creating a BPB. Ignored when reading one. |
MS-DOS version 7.0, part of DOS-Windows 95/98/ME, supported a 32-bit FAT filesystem format, and FAT volumes that were 2GiB or larger. Since this could result in file allocation tables comprising more than 65535 sectors, a further augmentation of the BPB was required.
However, Microsoft botched the design. Rather than placing the signature field for the new BPB variant in the same place as the signature fields in version 4.0 and Windows NT BPBs, Microsoft placed the signature field of version 7.0 BPBs in a different location, making it impossible to reliably distinguish between all BPB variants using the signature field values, as was originally intended.
See how version 7.0 BPBs should have been designed.
Microsoft also botched the signature byte value. The values
40 and 41 used in version 4.0 BPBs mirrored the
BPB version number. Therefore a version 7.0 BPB should use the value
70. However, a version 7.0 BPB uses the same signature byte
values as a version 4.0 BPB.
A common misconception is that this BPB is exclusive to 32-bit FAT. It is not. Just as there was no reason that the version 4.0 BPB could not be used for 12-bit FAT, there is no reason that the version 7.0 BPB cannot be used for filesystem formats other than 32-bit FAT.
Some older documentation, copied from Microsoft's documentation of
DOS-Windows 95, does not list any of the fields in a version 7.0 BPB after
offset 0x3A.
| offset from start of boot block | width in octets | description | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0B | 25 |
MS/PC-DOS version 3.4 BPB |
||||||||||
| 0x24 | 4 |
sectors per FAT This is the same as the sectors per FAT field in an MS/PC-DOS version 2.0 BPB, except that it is a 32-bit wide field. When writing a BPB: If the number of sectors per FAT is small enough to be stored as a 32-bit number, write it in this field. Otherwise write 0 in this field. When reading a BPB: If the field at offset 0x16 contains a non-zero value, that field is definitive and this field is ignored. Otherwise, this field is definitive if it contains a non-zero value, or if there is no other, wider, field. |
||||||||||
| 0x28 | 2 |
FAT flags These flags are used by the conversion process from 12-bit FAT or 16-bit FAT to 32-bit FAT. During the conversion process, the volume is formatted so that it holds both the original 12-bit/16-bit file allocation tables and the new 32-bit file allocation table. Because the first file allocation table starts in the same place (immediately after the boot area) irrespective of FAT width, this would be impossible in the absence of some mechanism to prevent the use of the first file allocation table by 32-bit FAT. These flags form that mechanism. During conversion, mirroring is disabled, and the active FAT number is set to the second file allocation table. After conversion, mirroring is then enabled. |
||||||||||
| 0x2A | 2 |
filesystem version number |
||||||||||
| 0x2C | 4 |
root directory start cluster This field only has meaning if the volume is formatted with the FAT filesystem format. The start of the root directory never changes in normal operation on FAT formatted volumes (although FAT defragmentation utilities may change it). For volumes formatted from scratch, the root directory will always start in the same, default, location. Volumes converted from other filesystem formats may have the root directory in another location (wherever there happened to be free space in the other filesystem format), however. For other filesystem formats, the root directory is not a primary filesystem structure (a superblock or a master file table is) and this field should be set to 0 when creating a BPB and ignored when reading one. |
||||||||||
| 0x30 | 2 |
superblock ("filesystem info sector") number The superblock in the FAT filesystem format is located in the boot area. If this field has the values 0 or 65535, or any value greater than the number of sectors reserved for the boot area, the filesystem does not have a superblock. This field is unused by the vanilla flavours of other filesystem formats. There is an extension to the HPFS and EXT2 filesystem formats (which have fixed-position superblocks in their vanilla flavours) where this field indicates the location of the superblock. This extension is not supported by the HPFS and EXT2 filesystem drivers in IBM/Microsoft operating systems or in Linux, though. |
||||||||||
| 0x32 | 2 |
block containing the backup of the boot block The backup boot block in the FAT filesystem format is located in the boot area. If this field has the values 0 or 65535, or any value greater than the number of sectors reserved for the boot area, the filesystem does not have a backup boot block. This field is largely useless in practice. When block zero is inaccessible, so is the value in this field. When block zero has been overwritten, so too will have been the value in this field. Many operating systems and volume repair utilities are hardwired to use block number 6 as the location of the backup of block zero on FAT format volumes. This field is unused by the vanilla flavours of other filesystem formats. |
||||||||||
| 0x34 | 12 |
reserved for future use Set to 0 when creating a BPB. Ignored when reading one. |
||||||||||
| 0x40 | 1 |
Disc unit number Same as the field at 0x24 in the MS/PC-DOS version 4.0 BPB |
||||||||||
| 0x41 | 1 |
"chkdsk" flags Same as the field at 0x25 in the MS/PC-DOS version 4.0 BPB |
||||||||||
| 0x42 | 1 |
Signature byte Same as the field at 0x26 in the MS/PC-DOS version 4.0 BPB (even though 40 and 41 are the wrong version numbers) |
||||||||||
| 0x43 | 4 |
Volume serial number Same as the field at 0x27 in the MS/PC-DOS version 4.0 BPB |
||||||||||
| 0x47 | 11 |
Volume label Same as the field at 0x2B in the MS/PC-DOS version 4.0 BPB |
||||||||||
| 0x52 | 8 |
Filesystem type Same as the field at 0x36 in the MS/PC-DOS version 4.0 BPB |
The NTFS filesystem format on Windows NT required that volumes with more than 232 sectors be supported and that the boot block contain pointers to the master file table. A variant of the "extended" BPB structure, with the same signature field in the same place but a different signature value to indicate a different variant, was created in order to support this.
The signature value is 0x80. Given that the signature byte
value mimics the BPB version number (as per the use of 40
and 41 in version 4.0 BPBs), it is reasonable that this
therefore be the version 8.0 BPB, even though there was no MS-DOS version
8.0.
A common misconception is that this BPB variant is exclusive to NTFS. It is not. There is no reason that a FAT, an HPFS, or an EXT2 volume could not employ this BPB type, for example. It is simply the case that because there is nothing to gain from doing so (the BPB checksum being unused in practice, the volume serial number being smaller than the serial number plus label that are available in the MS/PC-DOS version 4.0 BPB, and the other fields having no reasonable meanings for other filesystem formats), and quite a lot to lose (It becomes impossible to reliably determine the filesystem type by inspecting the BPB, since this BPB variant has no filesystem type field.), such use is not seen in practice.
| offset from start of boot block | width in octets | description |
|---|---|---|
| 0x0B | 25 |
MS/PC-DOS version 3.4 BPB |
| 0x24 | 1 |
Disc unit number Same as for the MS/PC-DOS version 4.0 BPB |
| 0x25 | 1 |
flags Same as for the MS/PC-DOS version 4.0 BPB |
| 0x26 | 1 |
Signature byte To distinguish this from the MS/PC-DOS version 4.0 BPB, the value 0x80 is used as a signature byte. |
| 0x27 | 1 |
reserved for future use Set to 0 when creating a BPB. Ignored when reading one. This appears to be a padding byte, present so that subsequent fields are aligned with natural word boundaries. |
| 0x28 | 8 |
Sectors in volume This is the same as the total number of sectors fields in MS/PC-DOS version 2.0 and 3.0 BPBs, except that it is a 64-bit wide field. When writing a BPB: If the number of sectors in the volume is small enough to be stored as a 64-bit number, write it in this field. Otherwise write 0 in this field. When reading a BPB: If the field at offset 0x13 contains a non-zero value, that field is definitive and this field is ignored. If the field at offset 0x13 contains zero but the field at offset 0x20 contains a non-zero value, that latter field is definitive and this field is ignored. Otherwise this field is definitive if it contains a non-zero value, or if there is no other, wider, field. |
| 0x30 | 8 |
MFT first cluster number This field only has meaning if the volume is formatted with the NTFS filesystem format. For other filesystem formats, this field should be set to 0 when creating a BPB and ignored when reading one. |
| 0x38 | 8 |
MFT mirror first cluster number This field only has meaning if the volume is formatted with the NTFS filesystem format. For other filesystem formats, this field should be set to 0 when creating a BPB and ignored when reading one. |
| 0x40 | 4 |
MFT record size This field only has meaning if the volume is formatted with the NTFS filesystem format. For other filesystem formats, this field should be set to 0 when creating a BPB and ignored when reading one. On NTFS: Values 0 to 127 represent MFT record sizes of 0 to 127 clusters. Values 128 to 255 represent MFT record sizes of 2256-N bytes. Other values are undefined. |
| 0x44 | 4 |
index block size This field only has meaning if the volume is formatted with the NTFS filesystem format. For other filesystem formats, this field should be set to 0 when creating a BPB and ignored when reading one. On NTFS: Values 0 to 127 represent index block sizes of 0 to 127 clusters. Values 128 to 255 represent index block sizes of 2256-N bytes. Other values are undefined. |
| 0x48 | 8 |
Volume serial number |
| 0x50 | 4 |
Checksum In theory this is a BPB checksum. In practice, no Microsoft software uses the value in this field or sets it to anything other than zero. |