A Fast File System for Unix

Reviewed by Lantian Zheng, Feb 1999

Goals

• Reimplement the Unix file system to provide higher throughput rate
• Preserve the interface of the existing Unix file system
• Present some functional enhancements

Strategies

• Use larger basic block (4096 or 8192 bytes)
• Improve file system organiztion and layout policy to increase the locality of reference

Organiztion

• Super-block (read-only, replicated, containing crutial data)
• Cylinder groups comprised of one or more consecutive cylinders
• Bookkeeping information associated with each cylinder group, including:
  • Redundant copy of the super-block
  • Space for inodes
  • Bitmap describing available blocks
  • summary information describing the usage to data blocks within the cylinder group

Layout policies

• Cluster related data while spread out unrelated data
• Take account of rotational positioning, when allocating blocks
• Two-levels structure
  • Global allocator decides which cylinder group to allocate, by wide summary information
  • Local allocator decides which blocks to allocate, using locally optimal scheme
  • Global allocator call local allocator with requests for specific blocks
• Reserve 5%-10% free space

Implementation

• Use 4096-bytes or larger blocks
• Use bitmap to keep track of free blocks
• Each block can be broken into addressable fragments which can be allocated separately
• Parameterize the processor capabilities and mass storage characteristic to allocate blocks in an optimum configuration-dependent way
• Other functional enhancements
  • Long file names
  • File locking
  • Symbolic links
  • Rename
  • Quotas

Questions

• Is it possible for a file to contain more than one fragmants?
• Why is it desired to reserve some free space?
• Why using bitmap to record free blocks instead of free list?
• Is it reasonable to contain rotational layout tables in super-block?
• Why does global allocator request for specific blocks instead of completely leaving the job of allocating blocks in a cylinder group to local allocator?
• Are the assumptions on which these improvement are based still valid today?
• Which optimizations still make sense given today's disks and CPUs?