Download presentation
Presentation is loading. Please wait.
Published byLinda Blair Modified over 9 years ago
1
Local Filesystems (part 1) CPS210 Spring 2006
2
Papers The Design and Implementation of a Log- Structured File System Mendel Rosenblum File System Logging Versus Clustering: A Performance Comparison Margo Seltzer
3
Surface organized into tracks
4
Parallel tracks form cylinders
5
Tracks broken up into sectors
6
Disk head position
7
Rotation is counter-clockwise
8
About to read a sector
9
After reading blue sector After BLUE read
10
Red request scheduled next After BLUE read
11
Seek to red’s track After BLUE readSeek for RED SEEK
12
Wait for red sector to reach head After BLUE readSeek for REDRotational latency ROTATESEEK
13
Read red sector After BLUE readSeek for REDRotational latencyAfter RED read ROTATESEEK
14
Unix index blocks Intuition Many files are small Length = 0, length = 1, length < 80,... Some files are huge (3 gigabytes) “Clever heuristic” in Unix FFS inode 12 (direct) block pointers: 12 * 8 KB = 96 KB Availability is “free” - you need inode to open() file anyway 3 indirect block pointers single, double, triple
15
Unix index blocks
20
Log-structured file system What is the high level motivation? Caches are getting bigger Disk reads are less important Disk traffic will be dominated by writes Why a log? Eliminate seeks (make all disk writes sequential) Easy crash-recovery Most writes are small meta-data updates Consecutive small writes will trigger seeks Some file systems perform these synchronously
21
LFS challenges Writes are easier, what about reads? How do we ensure large open spaces? Why does this matter?
22
LFS on disk structures
23
Segment cleaner LFS requires large open spaces Fragmentation will kill performance Use notion of segments Large contiguous areas of live/dead data 512 kb or 1MB Segment cleaner defragments disk Separate the old from the young Old data rarely changes Clean two differently
24
Threading vs copying Thread between segments
25
Segment cleaning Three steps Read segments into memory Identify live blocks in those segments Write live blocks to a small, clean segment Must also update file inodes Segment block summary for each segment
26
Segment block summaries Contains info about blocks in a segment For each file data block SBS has the file number and block number Also used to identify live/dead blocks Use file number from SBS with actual inode If same, block is live If different, block is dead Optimization: just keep inode versions
27
Cleaner policy questions When should the cleaner run? Continuously, at night, high utilization How many segments per cleaning? Tens, hundreds, … Which segments should be cleaned? How should live blocks be grouped?
28
Write cost Percent of bandwidth used for new data 1.0 is perfect (we only write new data) 10.0 isn’t great (1/10 written data is new) Ideal bimodal distribution of segments High utilization of old segments Low utilization of young segments Combines high utilization and low write cost
29
Initial simulation results Surprise!
30
Why the surprise? These segments decay slowly collecting dead blocks. In aggregate, they contain a lot of free blocks
31
Instead of greatest yield Use cost-benefit analysis Benefit/cost = (Yield * age)/cost = (1-u)*age/(1+u) Result Clean cold segments at higher utilization
32
Result
33
What do LFS results really mean? Workloads matter When is LFS better than FFS? When is FFS better than LFS?
34
More terminology Blocks Partial blocks, aka fragments Contiguous ranges of blocks, aka clusters Want to allocate indoes + data In same cylinder (no seeks) Want data In clusters on same track (also no seeks)
35
Challenges for FFS Reduce (eliminate?) synchronous writes Avoid fragmentation Why are meta-data writes synchronous?
36
Sequential performance vs file size Four phase benchmark: Create Read Overwrite Delete Ideal conditions Blank file system, no cleaner
37
Create results
38
Read results
39
Overwrite results
40
Delete results
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.