Hierarchical File System
|
|
Hierarchical File System (HFS), is a file system developed by Apple Computer for use on computers running Mac OS. Originally designed for use on floppy and hard disks, it can also be found on read-only media such as CD-ROMs.
| Contents |
History
HFS was introduced in September 1985 as a new file system for Macintosh computers. It superseded the Macintosh File System (MFS) which was a flat file system, used only on the earliest Mac models. Because Macintosh computers use richer data than other commonly available file systems such as FAT used by DOS or the original Unix file system would allow, Apple developed a new more appropriate file system, rather than adopting an existing specification. For example, HFS permits filenames up to 31 characters in length, supports metadata and dual forked (separate data and resource forks per file) files.
While HFS like most other file systems may be seen as a proprietary format, because it was so well documented there are usually solutions available to access HFS formatted disks from most modern operating systems.
In 1998, Apple introduced HFS Plus to address inefficient allocation of disk space in HFS and to add other improvements. HFS is still supported by current versions of Mac OS, but starting with Mac OS X an HFS volume cannot be used for booting.
Design
The Hierarchical File System divides a volume into logical blocks of 512 bytes. These logical blocks are then grouped together into allocation blocks which can contain one or more logical blocks depending on the total size of the volume. HFS uses a 16 bit value to address allocation blocks, limiting the number of allocation blocks to 65,536.
There are five structures that make up an HFS volume:
- Logical blocks 0 and 1 of the volume are the Boot Blocks, which contain system startup information. For example, the names of the System and Shell (usually the Finder) files which are loaded at startup.
- Logical block 2 contains the Master Directory Block (aka MDB). This defines a wide variety of data about the volume itself, for example date & time stamps for when the volume was created, the location of the other volume structures such as the Volume Bitmap or the size of logical structures such as allocation blocks. There is also a duplicate of the MDB called the Alternate Master Directory Block (aka Alternate MDB) located at the opposite end of the volume in the second to last logical block. This is intended mainly for use by disk utilities and is only updated when either the Catalog File or Extents Overflow File grow in size.
- Logical block 3 is the starting block of the Volume Bitmap, which keeps track of which allocation blocks are in use and which are free. Each allocation block on the volume is represented by a bit in the map, if the bit is set then the block is in use, if it is clear then the block is free to be used. Since the Volume Bitmap must have a bit to represent each allocation block, its size is determined by the size of the volume itself.
- The Extent Overflow File is a B*-tree that contains extra extents that record which allocation blocks are allocated to which files, once the initial three extents in the Catalog File are used up. Later versions also added the ability for the Extent Overflow File to store extents that record bad blocks, to prevent a machine from trying to write to them.
- The Catalog File is another B*-tree that contains records for all the files and directories stored in the volume. It stores four types of records. Each file is made up of a File Thread Record and a File Record while each directory is made up of a Directory Thread Record and a Directory Record. Files and directories in the Catalog File are located by their unique Catalog Node ID (or CNID).
- A File Thread Record stores just the name of the file and the CNID of its parent directory.
- A File Record stores a variety of metadata about the file including its CNID, the size of the file, three timestamps (when the file was created, last modified, last backed up), the first file extents of the data and resource forks and pointers to the file's first data and resource extent records in the Extent Overflow File. The File Record also stores two 16 byte fields that are used by the Finder to store attributes about the file including things like its creator code, type code, the window the file should appear in and its location within the window.
- A Directory Thread Record stores just the name of the directory and the CNID of its parent directory.
- A Directory Record which stores data like the number of files stored within the directory, the CNID of the directory, three timestamps (when the file was created, last modified, last backed up). Like the File Record, the Directory Record also stores two 16 byte fields for use by the Finder. These store things like the width & height and x & y co-ordinates for the window used to display the contents of the directory, the display mode (icon view, list view, etc) of the window and the position of the window's scroll bar.
See also
External links
- HFS specification (http://developer.apple.com/documentation/mac/Files/Files-99.html) from developer.apple.com
- The HFS Primer (http://www.macjournals.com/mwj/mwj_samples/MWJ_20030525.pdf.sit) (PDF) from MWJ (http://www.macjournals.com/mwj/)
- MacWindows (http://www.macwindows.com/) website for alternate platform solutions.
- Filesystems HOWTO - Macintosh Hierarchical Filesystem (http://www.tldp.org/HOWTO/Filesystems-HOWTO-7.html) - slightly out of dateja:HFS