- Disk space was expensive, so the file system worked hard to use every bit and byte of it extremely efficiently.
- Since hard drives were expensive, single disks were the focus, where one disk equals one volume.
In answer to Problem Number 1, developers made a choice to treat disk space as premium real estate. So they broke up user files into "blocks," each of which was just a small piece of the original file. In this way, the file system could cram pieces of a file into any available space on the disk rather than as one long piece. In this way, all of the hard disk space gets used with no "holes" left.
For word processing or database files, this works fine. Unfortunately, this "cramming" (or "fragmenting" as it's called) is not what digital studios want. Video content should be stored as contiguous blocks, not fragmented in blocks scattered around the disk. Notice in Table 1 how the various contemporary file systems have 2K-4K minimum sizes. (Compare this with GPFS' 256KB default block size.) With a 2 or 4KB minimum, pieces of a video file could well be scattered over a wide range of a hard disk's space, making retrieval slower.
Even if a hard disk were fast enough to make retrieval a non-issue [by no means a sure thing; see the Sidebar "Is Smaller Better?" on page 4), management problems would still arise from dealing with hundreds or thousands of gigabytes of storage using small block sizes. Tools have to cope with a huge index of disk space broken up this way. Simply waiting for a directory listing might take all day.
Equally restrictive was the upper limit on file sizes imposed by some systems. As Table 1 shows, Windows and many Mac and UniX systems limited files to 2GB. This is huge by office automation standards, but certainly not adequate in the video content creation environment.
A comparison of popular file systems with their block sizes and maximum file sizes (not that the minimum block size may vary depending on the size of the disk.)
|Where used||MacOS||Windows servers, XP||Linux workstations||Many UNIX workstations and servers||Various other UNIX workstations and servers||Windows 9x workstations|
|Minimum/default block size||4KB||2KB||4KB||4KB||2KB||4KB|
|Maximum file size||4GB (OS X), 2TB (OS 9), 2GB (OS 8.x and prior)||2TB||2-4TB (version-dependent)||2KB (1TB in theory)||2KB (version-dependent)||4GB|
In answer to Problem Number 2, file system designers made adding storage to a system quite a chore. Volumes had to be defined at installation time. Increasing the size of volumes on-the-fly was difficult if not impossible. (Never mind that hardware vendors didn't add a lot of extra room inside cases for adding drives. Even when mounted externally, there was an upper limit to the number of storage devices because there were only so many slots for the storage adapters.)
These decisions, which date from the dawn of computing, have continued to this day. In effect, until recently, file system developers aspired to create the ideal storage medium for nothing larger than still photos—and an "optimized" file system was one designed to keep thousands of megabyte or smaller files close at hand, with little thought to apportioning the sizeable chunks of contiguous space that larger files demand. Today, the "photos" file system designers must account for are multigigabyte uncompressed motion video clips stored for use with non-linear editors, which means a completely different way of distributing storage—and a much more challenging one, at that.