Log StructureFS
-
Upload
sajal-tiwari -
Category
Documents
-
view
216 -
download
0
Transcript of Log StructureFS
-
7/29/2019 Log StructureFS
1/21
The Design and Implementationof Log-Structure File System
M. Rosenblum and J. Ousterhout
-
7/29/2019 Log StructureFS
2/21
Introduction
CPU Speed increases dramatically
Memory Size increased Most Read hits in cache
Disk improves only on the size but access isstill very slow due to seek and rotationallatency Write must go to disk eventually
As a result Write dominate the traffic
Application has disk-bound problem
-
7/29/2019 Log StructureFS
3/21
Overview of LFS
Unix FFS Random write
Scan entire disk
Very slow restore consistency after crash
LFS Write new data to disk in sequence
Eliminate seek Faster crash recovery
The most recent log always at the end
-
7/29/2019 Log StructureFS
4/21
Traditional Unix FFS
Spread information around the disk Layout file sequentially but physically
separates different files
Inode separate from file contents Takes at least 5 I/O for each seek to
create new file
Causes too many small access
Only use 5% disk bandwidth Most of the time spent on seeking
-
7/29/2019 Log StructureFS
5/21
Sprite LFS
Inode not at fixed position
It written to the log
Use inode map to maintain the current location of theinode
It divided into blocks and store in the log Most of the time in cache for fast access (rarely need
disk access)
A fixed checkpoint on each disk store all the inodemap location
Only one single write of all information to diskrequired + inode map update
All information in a single contiguous segment
-
7/29/2019 Log StructureFS
6/21
Compare FFS/LFS
Task FFS LFS
Allocate diskaddress
Blockcreation
Segment Write
Allocate i-node Fixedlocation
Appended to log
Map anodenumbers into
disk addresses
Staticaddress
Lookup ini-node map
Maintain freespace
Bitmap Cleaner
Segment usagetable
-
7/29/2019 Log StructureFS
7/21
Space Management
Goal: keep large free extents to writenew data
Disk divided into segments(512kB/1MB)
Sprite Segment Cleaner
Threading between segments
Copying within segment
-
7/29/2019 Log StructureFS
8/21
Threading
Leave the live data in place
Thread the log through the free
extents Cons
Free space become many fragmented
Large contiguous write wont be possible
LFS cant access faster
-
7/29/2019 Log StructureFS
9/21
Copying and Compacted
Copy live data out of the log
Compact the data when it written
back Cons: Costly
-
7/29/2019 Log StructureFS
10/21
Segment Cleaning Mechanism
Read a number of Segments intomemory
Check if it is live data
If true, write it back to a smallernumber of clean segments
Mark segment as clean
-
7/29/2019 Log StructureFS
11/21
Segment summary block
Identify each piece of information insegment
Version number + inode = UID
Version number incremented in inodemap when file deleted
If UID of block mismatch to that ininode map when scanned, discard theblock
-
7/29/2019 Log StructureFS
12/21
-
7/29/2019 Log StructureFS
13/21
Disk space underutilized viaperformance
u < 0.8 will give better performance compare tocurrent Unix FFS
u < 0.5 will give better performance compare to theimproved Unix FFS
-
7/29/2019 Log StructureFS
14/21
Simulate more real situation
Data random access pattern
Uniform
Hot and cold
10% is hot and select 90% of the time 90% is cold and select 10% of the time
Cleaner use Greedy Policy
Choose the least-utilized segment to clean
Conclude hot and cold data should treatdifferently
-
7/29/2019 Log StructureFS
15/21
Cost Benefit Policy
Cold data is more stable and willlikely last longer
Assume Cold data = older (age) Clean segment with higher ratio
Group by age before rewrite
u
ageu
cost
agegeneratedspacefree
cost
benefit
1
1
-
7/29/2019 Log StructureFS
16/21
Left: bimodal distribution achieved
Cold cleaned at u=75%, hot at u=15%
Right: cost-benefit better, especially at utilization>60%
Cost Benefit Result
-
7/29/2019 Log StructureFS
17/21
Crash Recovery
Traditional Unix FFS:
Scan all metadata
Very costly especially for large storage
Sprite LFS Last operations locate at the end of the log
Fast access, recovery quicker
Checkpoint & roll-forward
Roll-forward hasnt integrated to Sprite while thepaper was written
Not focus here
-
7/29/2019 Log StructureFS
18/21
Micro-benchmarks
(small files)
Fig (a) Shows
performance oflarge number of
files create, readand delete
LFS 10 timesfaster than SunOS in create anddelete
LFS kept the disk17% busy whileSunOS kept thedisk busy 85%
Fig (b) Predicts LFS will
improve byanother factor of4-6 as CPUs getfaster
No improvementcan be expected
in SunOS
-
7/29/2019 Log StructureFS
19/21
Micro-benchmarks
(large files) 100Mbyte file (with
sequential, random)write, then read backsequentially
LFS gets higher write
bandwidth Same read bandwidth
in both FS
In the case of readsrequire seek (reread)in LFS, theperformance is lowerthan SunOS
- SunOS: pay additional cost for organizing diskLayout
- LFS: group information created at the same time,not optimal for reading randomly written files
-
7/29/2019 Log StructureFS
20/21
Real Usage Statistics
Previous result doesnt include cleaning overhead The table shows better prediction This real 4 months usage includes cleaning overhead
Write cost range is 1.2-1.6 More than half of cleaned segments empty Cleaning overhead limits write performance about
70% of the bandwidth for sequential writing In practice, possible to perform the cleaning at night
or idle period
-
7/29/2019 Log StructureFS
21/21
Thank You =)
~The end~