Other Metadata
Desktop filesystems increasingly are expected to be able to store arbitrary metadata. NTFS is fairly good at this task. The filesystem was designed quite early on in the process of developing the NT operating system. The designers weren’t told exactly what kinds of metadata they would need to store, so they provided a mechanism for storing arbitrary metadata in trees. This design has helped Microsoft as the operating system evolved—with ACLs, compression, encryption, and several other features being added to the filesystem simply by creating new trees.
The designers of BFS, still regarded by many as being close to the perfect desktop filesystem, took a different approach. Their inodes were quite small—only around 230 bytes. Storing one inode per disk block would have wasted a lot of space. Instead, they chose to store arbitrary key/value pairs in this space. For example, you could store information extracted from ID3 tags, allowing the file browser to display album and artist names and to search for a specific artist without knowing anything about MP3s. The designers of Haiku, which uses BFS, took this approach one step further and designed a very dense vector-art representation, which allows a file’s icon to be stored in this space as well. This is very important for a desktop graphical OS, since it allows the contents of a folder to be displayed very quickly. If the icon is stored in the inode, a single disk-read per file can load all of the information required to display the icon in the file browser, easily loading 100 per second in the worst case on a slow disk. Apple’s HFS+ has a problem with this capability, since it stores metadata in trees separate from the files and requires several disk reads for every file.
Filesystems are one of the least glamorous parts of an operating system, but still very important. When you use BeOS running on a 100 MHz system and see it taking less time to display a folder full of icons than OS X on a 2 GHz system with a much faster disk, you can attribute that difference to good design of the filesystem. When it takes a few seconds to seek to the end of an AVI file to find the information required to display the preview, you can blame that lag on the filesystem designer. Like much of the rest of an OS, a good filesystem is something you never think about, while a bad one is a constant source of frustration.