The disk surfaces are coated with a metallic oxide similar to that used on cassette music tapes or video tapes; data is magnetically recorded on these surfaces much the same way as on cassette or video tapes. The actual recording and "play-back" is done through a "read-write" head. Each surface has its own "read-write" head attached to a shared "access comb". When the disk drive is operating, the disk is constantly rotating; without moving the read-write heads, a circular path where data can be recorded or played-back passes under each head; this circular path is called a "track". The collection of tracks which can be thus accessed without moving the access comb (one track from each surface) is called a "cylinder". By moving the access comb in or out (towards or away from the spindle), the Disk IO Controller can store or recall data stored on different cylinders.
The Disk IO Controller copies blocks of data between main memory and the disk surface. These blocks of data are (generally) only a fraction of what could be stored on one track; each track is therefore divided up into smaller storage areas called "sectors", where each sector is large enough to hold one of these "blocks" of data.
Actually, use of the term "sector" implies that fixed sized storage area is used for all blocks of data stored on the disk; this is not true for some mainframe disk storage systems which use variable sized "physical blocks".
In order to perform disk IO, the processor must supply the Disk Controller with these three values (cylinder, surface, and sector numbers) plus a command (either "Read" or "Write") and the address of an area in memory to/from which the data block is to be copied.
Determining where an existing file begins on a disk (in physical terms) is part of an operating systsem process called "opening" the file. For an output file, "opening" involves the O/S finding a physical location where the file can be stored that is not already used by other files.
In order to determine where files start on a disk, each file system on the disk contains one or more index tables. This table is typically called a File Directory, or Root Directory, or even a Volume Table Of Contents (VTOC - from mainframes). The Directory contains (among other values) a list of names for all files stored on the disk and, for each file, its starting location in physical units (or something that can be easily translated into the disk physical units such as: cylinder, surface, sector).
No two files on the same file system are allowed to have the same access pathname; otherwise, the Operating System would not be able to tell which location should be used when a duplicated file name was supplied.
The size of the group of sectors assigned for a file is called the "allocation unit" size for the disk. A disk drive can only assign space for files as complete allocation units. If a sector contains 512 bytes and the allocation unit is 2 sectors, then a file with only 1 data byte will still use up 512x2 = 1024 bytes of disk space; in fact any file with between 1 and 1024 (inclusive) data bytes will use the same amount of space; a file with 1025 (to 2048) bytes will use 2 allocation units and so on.
While larger cluster sizes make for fewer allocation table entries for large files, the large cluster sizes may waste a lot of disk space if you have many files. With a cluster size of 64 on a 512-byte sector disk (32KB cluster size), on average half a cluster goes empty at the end of every file, wasting 16KB at the end of every file. Many files, especially many small files, may waste huge amounts of disk space.
The VTOC/directory contains a list of names of files stored on the disk and for each its starting location in terms of physical disk units (cylinder, surface, and sector numbers). Typically, a VTOC/directory entry may contain other information such as the file size, when the file was created, and file "attributes". File "Attributes" may indicate such things as that the file is to be "Read Only" i.e. it can not be erase or overwritten.
With Contiguous Space Allocation, if a programmer does not pre-request enough space, a run-time error will occur when the file runs out of space; if the programmer asks for too much space, a run-time error may occur because a big enough contiguous block may not exist. In addition, requesting more space than is needed wastes space on the disk which could be used by other files; in some systems, it is possible to ask for too much space and then give back whatever is not used after the file has been created, but this will only work if the file never "grows" or has data added to it and it does not get around the problem of finding an empty block as large as the initial request.
Assuming that the IBM mainframe disk uses "sectors" for disk storage (which it does not) and assuming our earlier example with a block of 9 contiguous unused sectors and another block of 8 unused sectors and no other unused space: A request for
SPACE=(SECTOR,10,2) would fail; | | primary-----------+ +----------secondary SPACE=(SECTOR,5,5) could handle a file up to 10 sectors; and SPACE=(SECTOR,8,4) could handle a file up to 16 sectors.
This is the system used for disk storage by MS-DOS. The "Chain" table is called the disk's File Allocation Table (or FAT). Each FAT entry is either a 12-bit or 16-bit value (depending upon the size of the disk).
MS-DOS terminology uses the term "cluster" instead of "allocation unit". File space clusters are normally 2 sectors of 512 bytes (although there is some variation with different disk types).
The "Boot" occupied the first sector (side 0, track 0, sector 1). This "Boot" record will be described in more detail later.
There were 2 copies of the FAT, in case one got damaged in some way. Each copy of the FAT occupied 2 sectors. Therefore the FAT copies used surface 0, track 1, sectors 2 to 5.
The Boot sector could be viewed as an "allocation block" (or "cluster") number 0; and the FAT's and Directory as "allocation block" number 1; therefore file space begins with "allocation block" number 2.
The Directory was 7 sectors long (where each sector was 512 bytes in length). Each directory entry is 32 bytes long (as described below) and therefore there were 112 entries in a 5.25" DSDD directory (7x512 = 32x112). This provided a limit to the maximum number of files/directories that could be stored in the "root" directory.
|0000h||E9 xx xx or EB xx 90 (JMP to bootstrap code)|
|0003h||OEM name and version (8 bytes)|
|000Bh||bytes per sector (2 bytes)|
|000Dh||sectors per allocation unit (1 byte)|
|000Eh||reserved sectors, starting at 0 (2 bytes)|
|0010h||number of copies of FAT (1 byte)|
|0011h||number of root directory entries (2
-- if <4087 12-bit FAT entries
-- otherwise 16-bit FAT entries
|0013h||number of sectors in (logical) drive (2 bytes)|
|0015h||media descriptor byte
-- 0F0h: 3.5" DSHD (18 sectors/track)
-- 0F8h: fixed disk
-- 0F9h: 5.25" DSHD (15 sectors/track)
-- ---- 3.5" DSDD (9 sectors/track)
-- 0FCh: 5.25" SS (9 sectors/track)
-- 0FDh: 5.25" DS (9 sectors/track)
-- ---- 8" SSSD (DOS 2+)
-- 0FEh: 5.25" SS (8 sectors/track)
-- ---- 8" SSSD (DOS 1)
-- ---- 8" DSDD
-- 0FFh: 5.25" DS (8 sectors/track)
|0016h||number of sectors per FAT (2 bytes)|
|0018h||sectors per track (2 bytes)|
|001Ah||number of heads (2 bytes)|
|001Ch||number of hidden sectors (4 bytes)|
|0020h||sectors in logical volume (DOS 4+; size>32MB) (4 bytes)|
|0024h||physical drive number (1 byte)|
|0026h||29h ("extended boot signature")|
|0027h||volume ID (4 bytes)|
|002Bh||volume label (11 bytes)|
|0036h||unused/reserved (8 bytes)|
WARNING: The IBM PC stores multi-byte values in Little-Endian order, which appears in a DEBUG dump listing to be backwards to what you might expect; so for example a 4-byte size that displays in the dump as 1A E2 04 00 must be reversed and read as 0004E21Ah.