Scribd
Upload
28 views

A Survey of File Systems

Unix FS was very simple and straightforwardly implemented - Too many long seeks. BSD UNIX folks did a redesign in the mid '80's - FFS: "fast File System" - Improved disk utilization, decreased response time.

Uploaded by

sushmsn
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
28 views

A Survey of File Systems

Unix FS was very simple and straightforwardly implemented - Too many long seeks. BSD UNIX folks did a redesign in the mid '80's - FFS: "fast File System" - Improved disk utilization, decreased response time.

Uploaded by

sushmsn
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Unix

• Original (i.e. 1970’s) Unix FS was very


simple and straightforwardly implemented
– Too many long seeks
A Survey of File Systems – No one uses this anymore

• BSD UNIX folks did a redesign in the mid


Steve Martin ’80’s
Dave Latham – FFS: “Fast File System”
– Improved disk utilization, decreased response
time
Copyright note: figures and some elements from slides by Hank Levy, CSE451, University of
Washington. Thank you, Hank!
– Basic idea is FFS is aware of disk structure
• I.e., place related things on nearby cylinders to
reduce seeks

Unix FS Unix FFS


• Original (non-FFS) unix FS had two major problems: • FFS addressed these problems using notion of a cylinder group
– 1. data blocks are allocated randomly in aging file systems – disk partitioned into groups of cylinders
• blocks for the same file allocated sequentially when FS is new – data blocks from a file all placed in same cylinder group
• as FS “ages” and fills, need to allocate blocks freed up when other – files in same directory placed in same cylinder group
files are deleted – inode for file in same cylinder group as file’s data
– problem: deleted files are essentially randomly placed
– so, blocks for new files become scattered across the disk! • Introduces a free space requirement
– 2. inodes are allocated far from blocks – to be able to allocate according to cylinder group, the disk must have
• all inodes at beginning of disk, far from data free space scattered across all cylinders
• traversing file name paths, manipulating files, directories requires – in FFS, 10% of the disk is reserved just for this purpose!
going back and forth from inodes to data blocks
• FFS uses a larger block (4KB)
• Also, small blocks (1KB) caused two problems: – allows for very large files (1MB only uses 2 level indirect)
– low bandwidth utilization – but, introduces internal fragmentation
– small max file size (function of block size) • there are many small files (I.e., <4KB)
– fix: introduce “fragments”
• 1KB pieces of a block
• Performance was unacceptable before long.

Log-Structured File System (LFS) LSF (2)


• LFS was designed in response to two trends in workload • The basic idea: treat the entire disk as a single log for
and disk technology: appending
– 1. Disk bandwidth scaling significantly (40% a year) – collect writes in the disk buffer cache, and write out the entire
• but, latency is not collection of writes in one large request
– 2. Large main memories in machines • leverages disk bandwith with large sequential write
• therefore, large buffer caches
• no seeks at all! (assuming head at end of log)
– absorb large fraction of read requests in caches
• can use for writes as well – all info written to disk is appended to log
– coalesce small writes into large writes • data blocks, attributes, inodes, directories, .etc.

• LFS takes advantage of both to increase FS • There are two main challenges with LFS:
performance – 1. locating data written in the log
• FFS places files in a well-known location, LFS writes data “at the
• Solves some FFS problems: end of the log”
– FFS: placement improved, but can still have many small seeks – 2. managing free space on the disk
• possibly related files are physically separated • disk is finite, and therefore log must be finite
• inodes separated from files (small seeks) • cannot always append to log!
• directory entries separate from inodes – need to recover deleted blocks in old part of log
FFS: metadata required synchronous writes d t fill h l t db d bl k

1
LSF (3) Windows FAT
• How LFS locates data • “The” Windows FS up until NTFS became prevalent.
– Two flavors:
– LFS appends inodes to end of log, just like data • FAT16 (older, 2.1 GB file size limit)
• makes them hard to find • FAT32 (2 TB file size limit, new features)
– So, we use another level of indirection: inode maps
– inode maps map file #s to inode location, kept in a checkpoint • Basically, here’s how it works:
region – File Allocation Table (yes, actual table) at the top of the volume.
• Two copies kept in case one becomes damaged.
• Checkpoint region has a fixed location
– FAT location and root directory stored in fixed location for boot.
– Cache inode maps in memory for performance – Disk is allocated in ‘clusters’, the size of which is determined by the size of the
volume.
• Why do you think this is?
• LFS: append-only quickly eats up all disk space! – On file creation, entry is created in directory file as well as in FAT.
– need to recover deleted blocks • Files are given first open location in drive.
– fragment log into segments and thread on disk • If more than one cluster in file, entry in FAT points to next cluster.

• segments can be anywhere


• Advantages:
– reclaim space by cleaning segments
– Simple!
• read segment
• copy live data to end of log • Disadvantages:
• now have free segment you can reuse! – Slow, dangerous to have all volume information in one place, inefficient use of
– cleaning is a big problem disk space, as size of volume increases performance decreases, etc.
• costly overhead, when do you do it?

Windows NTFS
• Windows Network File System
– Introduced with Windows NT and the default used for Windows XP.

• Very complicated file system


– There are whole books on this, check web for more info.

• Here are the absolute basics. . .


– Still uses the concept of clusters, size of which range from 512 B to 64
KB
– For each file created, a record is created in the Master File Table.
• This is not a FAT!
– Does not contain cluster addresses, contains file attributes.
• Record is used to locate possibly scattered clusters of file.
• ~12.5% of the disk is reserved for MFT
– NTFS attempts to lay out all files contiguously.
• However, in addition to MFT, each cluster also records data about the next
cluster in the file.
– Directories are stored as B-trees, with lazy deletion!
• What does this mean?
– Operations take the form of transactions against the file system.
• This allows for guarantees to be made for data consistency, improving file
system reliability

You might also like