In order to create the illusion of files from the block oriented disk drives, the OS must keep track of the location of the sectors containing the data of the file. This is accomplished by maintaining a set of data structures both in memory and on disk that keep track of where data is allocated to each file, and the name to file mapping encoded in the directoiry structure.
The simplest alloaction of files is a contiguous allocation of sectors to each file. A directory entry would contain the name of the file, its size in bytes and the first and last sector of the file. This results in a fast read of a given file and a compact representation, but also of sizable external fragmentation which can require compaction to correct. The analog in memory management is the base/limit register system of memory allocation.
As with memory management, we turn to more complex data structures and non contiguous allocation to solve the problems. We can use a bitmap to record the allocated and unallocated sectors on the disk, and keep a list of sectors assigned to each file in its directory entry. This isn't often used, because it makes searching for free space difficult and replicates the allocation information in the file itself. (When it is used, the bitmap is kept both on disk and in memory).
The other system that is used in file systems and in memory management is a linked list. A simple mechanism is to take one integer out of every file block and us that as the next sector following this one (similar to linking the holes in memory management).
The free list is kept as a separate file.
This is an improovement over bitmaps in efficiancy of storage use, but has a significant drawback in that finding the proper sector for a random access is expensive. Finding the right sector containing a random sector is as expensive as reading to that point in the file.
To solve this we collect the sector pointers into a table (usually cached in main memory) separate from the files. Now the OS can follow the separate pointers to find the appropriate sector for a random access without reading each disk block. Furthermore, the conceptual disk blocks and the physical disk blocks now have the same size. This is essentially the FAT file system of MS-DOS.
Another organization is one optimized for small files (which research has shown doiminate the file system, in the sense that most files are small1) while accomodating large ones. The system is called the index node or i-node system.
An i-node2 contains the attributes of the file and pointers to its first ferw blocks.
This results in increasing access times for blocks later in the file. Large files will have longer access times to the end of the file. I-nodes specifically optimize for short files.
Directories are generally simply files with a special interpretation. Some directory structures contain the name of a file, its attributes and a pointer3 either into its FAT list or to its i-node.
This choice bears directly on the implementation of linking. If attributes are stored directly in the directory node, (hard) linking is difficult because changes to the file must be mirrored in all directories. If the directory entry simply points to a structure (like an i-node) that holds the attributes internally, only that structure needs to be updated.
There are two approaches to having multiple disks on a system (where disks are really devices that export a file system interface). Either the disks can be explicit or implicit. An example of explicit disk naming is MS-DOS's A:\SYS\FILE.TXT. Other systems from IBM VM/CMS to AmigaDOS have done the same thing. Making disks explicit makes the boundaries between physical devices clear. UNIX(R) clouds the issues by allowing one device to be grafted onto the name space established by another at a mount point. A mount point looks like a directory to the user, but to the operating system marks the boundary between devices. As a result, the file system appears to be one seamless name space, but there are subsets of the space on different devices.