CS 332 w22 — File System Implementation

Having covered the general file system abstraction and played around with the file system API, now it's time to take a look at what's going on underneath. We know that persistent storage disks are block devices, meaning we read from and write to them in fixed-size blocks. Meanwhile, the operating system lets users jump to arbitrary points within a file and start reading and writing away. Clearly there must be some machinery to bridge the gap between device interface and system call. This material should emphasize that careful data structure design plays a significant part in building an operating system.

Read this part of the OSPP chapter on file system implementation. Don't worry about the details of directory internals on p. 6, the takeaway is the choice of data structures is a big part of file system design. Important terms to make sure you understand after you're finished:

• inode
• data block
• direct pointer
• indirect pointer

• Primary Roles of the OS for the file system
  1. Hide hardware specific interface
  2. Allocate disk blocks
  3. Check permissions
  4. Understand directory file structure
  5. Maintain metadata
  6. Performance
  7. Flexibility
• The concept of a file system is simple
  • the implementation of the abstraction for secondary storage
    • abstraction = files
  • logical organization of files into directories
    • the directory hierarchy
  • sharing of data among processes, people and machines
    • access control, consistency, …

• Some file systems provide different access methods that specify ways the application will access data
  • sequential access
    • read bytes in order
  • direct access
    • random access given a block/byte number
  • record access
    • file is array of fixed- or variable-sized records
  • indexed access
    • file system contains an index to a particular field of each record in a file
    • apps can find a file based on value in that record (similar to a database)
• Why do we care about distinguishing sequential from direct access?
  • what might the file system do differently in these cases?¹

• A directory is typically just a file that happens to contain special metadata
  • directory = list of (name of file, file attributes)
  • attributes include such things as:
    • size, protection, location on disk, creation time, access time, …
  • the directory list is usually unordered (effectively random)
    • when you type ls, the ls command sorts the results for you

• Let's say you want to open "/one/two/three"

fd = open("/one/two/three", O_RDWR);

• What goes on inside the file system?
  • open directory "/" (well known, can always find)
  • search the directory for "one", get location of "one"
  • open directory "one", search for "two", get location of "two"
  • open directory "two", search for "three", get location of "three"
  • open file "three"
  • (of course, permissions are checked at each step)
• File system spends lots of time walking down directory paths
  • this is why open is separate from read/write
    • to preserve the location, etc. of a file between individual reads and writes (session state)
  • OS will cache prefix lookups to enhance performance
    • /a/b, /a/bb, /a/bbb all share the "/a" prefix

• File system must implement some kind of protection system
  • to control who can access a file (user)
  • to control how they can access it (e.g., read, write, or exec)
• More generally:
  • generalize files to objects (the "what")
  • generalize users to principals (the "who", user or program)
  • generalize read/write to actions (the "how", or operations)
• A protection system dictates whether a given action performed by a given principal on a given object should be allowed
  • e.g., you can read or write your files, but others cannot
  • e.g., your can read /etc/motd but you cannot write to it

• Created in the 1970s for MS-DOS and early versions of Windows
• Various enhancements over the years
• FAT-32: volumns of up to 2²⁸ blocks, files up to 2³² - 1 bytes

• Named for the file allocation table

  • array of 32-bit entries (hence the 32 in FAT-32)
  • each file is a linked list of FAT entries, one entry per block

  

  • file's number is the index of its first entry
• Allocation is typically simple, something like next fit
  • May scatter a file's blocks across volume, requiring defragmentation
    • Read files and rewrite them to new, more consolidated location
• FAT continues to be used for its simplicity and portability
  • USB flash storage, camera memory cards
• Downsides
  • poor locality
  • poor random access
  • limited metadata and access control
  • no hard links
  • limitations on volumn and file size
  • doesn't support modern reliability techniques

• Dennis Ritchie and Ken Thompson, Bell Labs, 1969

"UNIX rose from the ashes of a multi-organizational effort in the early 1960s to develop a dependable timesharing operating system" – Multics

• Designed for a "workgroup" sharing a single system
• Did its job exceedingly well
  • Although it has been stretched in many directions and made ugly in the process
• A wonderful study in engineering tradeoffs

(Old) Unix disks are divided into five parts:

• Boot block
  • can boot the system by loading from this block
• Superblock
  • specifies boundaries of next 3 areas, and contains head of freelists of inodes and file blocks
• inode area
  • contains descriptors (inodes) for each file on the disk; all inodes are the same size; head of freelist is in the superblock
• File contents area
  • fixed-size blocks; head of freelist is in the superblock
• Swap area
  • holds processes that have been swapped out of memory

• Released in 1993, big improvement over FAT
• Key difference from FFS: track variable-sized extents rather than fixed-size blocks
  • An extent is a contiguous set of blocks
  • The modern Linux file system ext4 uses this approach
• A master file table (MFT) stores an array of 1 KB records
  • Each MFT record has information about a file and variable sized attribute records
  • The attribute records store both file data and metadata
  • An attribute can be resident (stored directly within the MFT record) or nonresident (MFT record contains pointers to the start and end of the extent storing the data)

• A basic file with two data extents:

  

• A small file's data can be resident:

  

• A large file may span multiple MFT records, in which case the first record stores an attribute list that indicates where to find each attribute

  

  

• ZFS is a popular open-source example (formerly the Zettabyte File System)
• See the OSTEP chapter on Log-Structured File Systems (LFS) for another example
• Goal is to transform random writes into sequential writes
  • Instead of updating various parts of the on-disk data structure, requiring several non-sequential writes
  • Write new versions to a sequential chunk of free space
  • Because small writes are expensive and large memory caches will greatly reduce the number of reads from disk, this can be a big performance boost for write-heavy workloads