1 / 15

File Systems Implementation

File Systems Implementation. Recap. What we have covered: User-level view of FS Storing files: contiguous, linked list, memory table, FAT, I-nodes Directories: all attributes in table, variable name length, search Sharing files: hard and soft links

tavia
Download Presentation

File Systems Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. File Systems Implementation

  2. Recap • What we have covered: • User-level view of FS • Storing files: contiguous, linked list, memory table, FAT, I-nodes • Directories: all attributes in table, variable name length, search • Sharing files: hard and soft links • Managing space: block size, tracking free space (linked list, bitmap) • Today: • Disk quotas • FS Reliability: Backups and FS Consistency • FS Performance

  3. Managing Disk Quotas • Sys admin gives each user max space • Open file table has entry to Quota table • Soft limit violations result in warnings • Hard limit violations result in errors • Check limits on login

  4. File System Reliability • 2 considerations: backups and consistency • Why backup? • Recover from disaster • Recover from stupidity • Where to backup? Tertiary storage • Tape: holds 10 or 100s of GBs, costs pennies/GB • sequential access  high random access time • Backup takes time and space

  5. Backup Issues • Should the entire FS be backup up? • Binaries, special I/O files usually not backed up • Do not backup unmodified files since last backup • Incremental dumps: complete per month, modified files daily • Compress data before writing to tape • How to backup an active FS? • Not acceptable to take system offline during backup hours • Security of backup media

  6. Backup Strategies • Physical Dump • Start from block 0 of disk, write all blocks in order, stop after last • Pros: Simple to implement, speed • Cons: skip directories, incremental dumps, restore some file • No point dumping unused blocks, avoiding it is a big overhead • How to dump bad blocks? • Logical Dump • Start at a directory • dump all directories and files changed since base date • Base date could be of last incremental dump, last full dump, etc. • Also dump all dirs (even unmodified) in path to a modified file

  7. Logical Dumps • Why dump unmodified directories? • Restore files on a fresh FS • To incrementally recover a single file File that has not changed

  8. A Dumping Algorithm Algorithm: • Mark all dirs & modified files • Unmark dirs with no mod. files • Dump dirs • Dump modified files

  9. Logical Dumping Issues • Reconstruct the free block list on restore • Maintaining consistency across symbolic links • UNIX files with holes • Should never dump special files, e.g. named pipes

  10. File System Consistency • System crash before modified files written back • Leads to inconsistency in FS • fsck (UNIX) & scandisk (Windows) check FS consistency • Algorithm: • Build 2 tables, each containing counter for all blocks (init to 0) • 1st table checks how many times a block is in a file • 2nd table records how often block is present in the free list • >1 not possible if using a bitmap • Read all i-nodes, and modify table 1 • Read free-list and modify table 2 • Consistent state if block is either in table 1 or 2, but not both

  11. Inconsistent FS examples • Consistent • missing block 2: add it to free list • Duplicate block 4 in free list: rebuild free list • Duplicate block 5 in data list: copy block and add it to one file

  12. Check Directory System • Use a per-file table instead of per-block • Parse entire directory structure, starting at the root • Increment the counter for each file you encounter • This value can be >1 due to hard links • Symbolic links are ignored • Compare counts in table with link counts in the i-node • If i-node count > our directory count (wastes space) • If i-node count < our directory count (catastrophic)

  13. FS Performance • Access to disk is much slower than access to memory • Optimizations needed to get best performance • 3 possible approaches: caching, prefetching, disk layout • Block or buffer cache: • Read/write from and to the cache.

  14. Block Cache Replacement • Which cache block to replace? • Could use any page replacement algorithm • Possible to implement perfect LRU • Since much lesser frequency of cache access • Move block to front of queue • Perfect LRU is undesirable. We should also answer: • Is the block essential to consistency of system? • Will this block be needed again soon? • When to write back other blocks? • Update daemon in UNIX calls sync system call every 30 s • MS-DOS uses write-through caches

  15. Other Approaches • Pre-fetching or Block Read Ahead • Get a block in cache before it is needed (e.g. next file block) • Need to keep track if access is sequential or random • Reducing disk arm motion • Put blocks likely to be accessed together in same cylinder • Easy with bitmap, possible with over-provisioning in free lists • Modify i-node placements

More Related