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~