|
| |
Hierarchical File System
|
| |
Apple Computer
|
| |
System 21
|
| |
September 17 1985
|
| |
<tt>Apple_HFS</tt> ( Apple Partition Map )<br><tt>0xAF</tt> ( MBR )
|
| |
B-tree
|
| |
B-tree
|
| |
B-tree
|
| |
65535
|
| |
4 GiB
|
| |
31 characters
|
| |
2 TiB
|
| |
Creation, modification, backup
|
| |
January 1, 1904 - February 6, 2040
|
| |
Only 2 (data and resource)
|
| |
Color (3 bits, all other flags 1 bit), locked, custom icon, bundle, invisible, alias, system, stationery, inited, no INIT resources, shared, desktop
|
| |
AppleShare
|
| |
Yes (third-party), Stacker
|
| |
No
|
('''HFS'''), is a
File System developed by
Apple Computer for use on computers running
Mac OS . Originally designed for use on
Floppy and
Hard Disk s, it can also be found on read-only media such as
CD-ROM s. HFS is the name used by developers, but in user documentation the format is referred to as '''Mac OS Standard''' to differentiate it from its successor
HFS Plus which is called '''Mac OS Extended'''.
The
Macintosh File System (MFS) was the original Macintosh file system, introduced in 1984. Because Macintosh computers use richer data than other commonly available file systems would allow (such as
DOS 's
FAT ), Apple developed a new file system. For example, MFS permits filenames up to 31 characters in length, and supports dual forked (separate data and
Resource Fork s per file) files.
Since MFS was intended to be used on very small and slow media, namely
Floppy Disk s, several design decisions were made to increase performance. This led to a number of unique design decisions. For instance, MFS refers to files not by name, but by a single volume-wide unique ID, the ''handle''. When a directory (folder) is opened, the Mac OS draws the contents of the folder and then caches the handles. When a user double-clicks a file to open it, the
Finder simply passes the handle back into the system in order to find the file.
MFS stored all of the file and directory listing information in a single file. The Finder nevertheless supported the "illusion" of folders, by storing all files as a directory handle/file handle pair. To display the contents of a particular folder, MFS would scan the directory for all files in that handle. There was no need to find a separate file containing the directory listing.
While the MFS system worked well for small file systems, the introduction of larger media, notably
Hard Drive s, revealed serious preformance problems. The main concern was the time needed to display the contents of a folder; under MFS the system had to search the entire directory and build up a list. This worked fine for a system with a few hundred kilobytes of storage and perhaps a hundred files, but as the systems grew into megabytes and thousands of files, the performance degraded rapidly.
- -tree" class="copylinks">B
tree structures that can be searched very quickly regardless of size. HFS also re-designed various structures to be able to hold larger numbers, 16-bit integers being replaced by 32-bit almost universally. Oddly, one of the few places this "upsizing" did not take place was the file directory itself, which limits HFS to a total of 64k files. The resulting system was released in 1985 .
Work on creating HFS from MFS was done by Patrick Dirks and Bill Bruffy. It was all written in 68K assembly language. The signature of an HFS disk is "BD", which stands for Big Disk, but also for Bruffy and Dirks!
Generally, HFS is very similar to MFS. As in MFS, the locations of files for the entire drive are stored in a single directory structure, the . This contrasts strongly with almost all other file systems, where the directory information is isolated to those files in a particular directory – how most people would likely believe even HFS works. This leads to real performance problems when the system allows
Multitasking , as only one program can write to this structure at a time, meaning that many programs may be waiting in queue due to one program "hogging" the system. It is also a serious reliability concern, as damage to this file can destroy the entire file system; with structure distributed across the disk, damaging a single directory is generally non-fatal and it can often be re-constructed with data held in the non-damaged portions.
- tree —potentially cached— meant that "user perceived" performance was superb. HFS was a primary reason that the Mac seemed so much faster than other GUI's of the era. It is arguable, however, whether this results in a real-world performance difference on modern hardware.
While HFS is a proprietary file system format, it's well documented so there are usually solutions available to access HFS formatted disks from most modern
Operating System s.
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 .
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 , 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 (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 , 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.
- -tree" class="copylinks">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.
- -tree" class="copylinks">B
tree that contains records for all the files and directories stored in the volume. It stores four types of records. Each file consists of a File Thread Record and a File Record while each directory consists 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 stores just the name of the file and the CNID of its parent directory.
- A 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 Extent s 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 stores just the name of the directory and the CNID of its parent directory.
- A which stores data like the number of files stored within the directory, the CNID of the directory, three timestamps (when the directory 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.
