• Save
Fast File System
Upcoming SlideShare
Loading in...5
×
 

Fast File System

on

  • 567 views

Class presentation.

Class presentation.

Statistics

Views

Total Views
567
Views on SlideShare
567
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fast File System Fast File System Presentation Transcript

  • A Fast File System for UNIX Marshall K. McKusick, William N. Joy, Samuel J. Leffler, and Robert S. Fabry Slides by Aleatha Parker-Wood Tuesday, April 6, 2010
  • State of the Art • Bell Labs UNIX file system for the PDP-11 (referred to as “old filesystem” or OldFS) • Disks are divided into physical partitions which contain a file system • Linked list of free blocks stored in superblock • inodes point either directly to blocks or to indirect blocks Tuesday, April 6, 2010
  • Inode Layout in OldFS inodes data • All inodes are stored at the beginning of the disk region for the filesystem • Incurs long seek times for every access • inodes for files are unlikely to be adjacent to their containing directory’s inodes or to each other • More seek time incurred Tuesday, April 6, 2010
  • Data Layout in OldFS • Completely agnostic to physical storage device • Consecutive file blocks unlikely to be on the same cylinder • Even more seeking • 512 byte blocks (increased to 1024 bytes) • Increasing the block size improved performance by a factor of 2 • Ergo: room for improvement! Tuesday, April 6, 2010
  • Performance for OldFS • Old system using 4% of disk bandwidth • Performance good initially (175kbps), but degraded over time (30kbps) • Free list became increasingly disorganized as file system was used... • Blocks allocated in increasingly random locations Tuesday, April 6, 2010
  • The Fast File System (FFS) • Disk partitions divided into “cylinder groups” • 4K minimum block size • ensures few levels of indirection (2 for files < than 4 GB) • Blocks are broken into fragments to accommodate small files Tuesday, April 6, 2010
  • Cylinder Groups • Bookkeeping info stored for each cylinder group • Backup copy of superblock • Space for inodes • A bit map of free blocks/fragments • A static number of inodes allocated at creation time • Bookkeeping info stored at a varying offset for each group (so losing the top platter will not result in complete data loss) Tuesday, April 6, 2010
  • Fragments • 2,4, or 8 per block (minimum size is a disk sector, 512 bytes) • Files never use more than one fragmented block • Writing to a file which occupies a fragmented block either fills the current block (if room is available) or allocates a new block. • Expanding files a fragment at a time causes frequent copying, writing in full blocks is optimal. Tuesday, April 6, 2010
  • Layout Optimizations • Optimize for the processor and mass storage device (usually disk) • Cylinder aware • Chooses rotationally optimal blocks (either consecutive or delayed) • Stores rotational layout tables to find positions with data already written nearby • Trade off between localizing data references and spreading unrelated data across cylinder groups. Tuesday, April 6, 2010
  • Layout Policies: Inodes • Inodes of files in a directory often accessed together • For instance, ls reads every inode in the directory • Keep inodes in same cylinder group • When creating new directories, choose cylinder group with few current inodes and directories Tuesday, April 6, 2010
  • Layout Policies: Data Blocks • Place all data blocks for a file within the same cylinder group • Preferably at rotationally optimal placements • If file is greater than 48K (i.e., an indirect block is needed), move to new cylinder group (you had to seek anyway...) • Likewise for every MB thereafter Tuesday, April 6, 2010
  • So when you say “Fast” File System.... Tuesday, April 6, 2010
  • Read Throughput Processor/ Speed Max read Type Bus (Kbps) bandwidth % %CPU 750/ Old 1024 UNIBUS 29 983 3 11 750/ New 4096/1024 UNIBUS 221 983 22 43 750/ New 8192/1024 UNIBUS 233 983 24 29 750/ New 4096/1024 MASSBUS 466 983 47 73 750/ New 8192/1024 MASSBUS 466 983 47 54 Tuesday, April 6, 2010
  • Write Throughput Processor/ Speed Max write Type Bus (Kbps) bandwidth % %CPU 750/ Old 1024 UNIBUS 48 983 5 29 750/ New 4096/1024 UNIBUS 142 983 14 43 750/ New 8192/1024 UNIBUS 215 983 22 46 750/ New 4096/1024 MASSBUS 323 983 33 94 750/ New 8192/1024 MASSBUS 466 983 47 95 Tuesday, April 6, 2010
  • Other metrics... • When running ls for large directories containing other directories, disk accesses for inodes cut in two • Large directories containing only files cut by up to a factor of eight • Transfer rates stable over time • Throughput varies with amount of free space maintained (reduced by half when system is full) Tuesday, April 6, 2010
  • Other Enhancements • Arbitrary length file names (ok, 512 bytes) • Advisory file locking • Shared or exclusive • Applied or removed only on open files • Symbolic links, a la Multics • Atomic rename operation • Quotas Tuesday, April 6, 2010
  • Conclusions • Taking advantage of disk geometry and access patterns resulted in 10- fold improvement in both read and write throughput • Improvements in block layout increased locality while reducing wasted space • Hardware matters! Tuesday, April 6, 2010
  • Thank you. Questions? Tuesday, April 6, 2010