Filesystems for the Macintosh were developed to handle the unique nature of the OS. In the beginning Apple was not a GUI based OS. In fact DOS was originally used and this was later to become Apple ProDOS. Both of these Operating Systems were very much command line driven. With the release of the original Macintosh, Apple boldly introduced the world to the Finder (the Graphical User Interface).

Apple needed a way to interact with the underlying file-system on disk. Because the GUI environment was controlled by a mouse selecting a file to open… Apple needed a way for the operating system to know which application should launch when a file was clicked on. Apple developed what became known as a forked file system. One fork (the data fork) contained the structured data while the resource fork contained the file’s metadata. Metadata at that time contained such things as the association between file/data and the application used to create the file, thumbnail previews and what type of file it was (.jpg, .tiff, .psd, etc.).

To keep track of the dual forked file, Apple needed a filesystem that could keep track of both halves of the file and have them “appear” as one. Apple developed MFS (or the Macintosh File System) to handle the storing of data on disk. The downside to this filesystem was that it was flat… meaning it did not allow for nested folders or a hierarchy or a means of organizing the data on disk. Realize… at that point in time the Macintosh was still booting from floppy disks and that in and of itself allowed users to store similar data on separate disks. Unfortunately, MFS had a upper limit on capacity (20MBs). This quickly became a problem because it was not long after the introduction of the Macintosh that hard drives as we known them today started to make their way into personal computing. Apple needed a way to address the additional space provided for in these new devices! As mentioned earlier MFS stored all files on the root level of the disk. This presented a performance problem. As anyone whose worked with databases knows… the more records that are added to a table the slower that table is to preform. Meaning anytime someone needed to access a file, the OS had to read from all files on disk. By breaking down files into groupings or directories… file searches became significantly faster. And thus HFS (or the Hierarchical File System) was born!

The problem with storage is that it grows exponentially! There was a time that a 32MB hard drive seemed exceedingly large. “You’re never going to full that thing!” Today to can’t even purchase a USB thumb drive that small. By the late 1990’s it was clear that Apple’s original filesystem design was start to show it’s age. HFS was limited to 65,536 blocks per volume (or partition). When disk capacity was small (say a 32MB hard drive) this wasn’t a problem. If you had a 1KB file and your block size was 512 bytes, it would take up two blocks of disk space without wasting disk. BUT as disk became bigger so too did the block size. On a rather small 128MB because the the block limitation the minimum block size became 2KB. The OS would write that same 1KB file to one block occupying 1KB of the 2KB block wasting 1KB in the process. Now this is a very basic illustration but now let’s imagine a 1GB hard disk… the size of the data contained in the file would not increase but the block size had too(16KB)! Thus the amount of disk wasted became greater! Apple introduced HFS Plus (or HFS Extended) with it 8.1 OS release. To address the file allocation block problem, certainly Apple would say that’s not the only reason it created HFS Plus. For a more detailed look into the technical aspects of HFS you can read Technical Note TN1150 – HFS Plus Volume Format which can be found at: http://developer.apple.com/mac/library/technotes/tn/tn1150.html#HFSPlusBasics