CS 423 Operating System Design: Log-Structured File Systems - - PowerPoint PPT Presentation

cs 423 operating system design log structured file systems
SMART_READER_LITE
LIVE PREVIEW

CS 423 Operating System Design: Log-Structured File Systems - - PowerPoint PPT Presentation

CS 423 Operating System Design: Log-Structured File Systems Professor Tianyin Xu CS 423: Operating Systems Design MP1/MP2/Midterm Stats CS 423: Operating Systems Design 2 Recap File Disk block Inode To read/write a file, we


slide-1
SLIDE 1

CS 423: Operating Systems Design

Professor Tianyin Xu

CS 423 Operating System Design: Log-Structured File Systems

slide-2
SLIDE 2

CS 423: Operating Systems Design

MP1/MP2/Midterm Stats

2

slide-3
SLIDE 3

CS 423: Operating Systems Design

Recap

3

■ File ■ Disk block ■ Inode ■ To read/write a file, we have to find the

inode of the file first.

■ Sequential reads/writes are MUCH faster than

random reads/writes

■ Why?

slide-4
SLIDE 4

CS 423: Operating Systems Design 4

Alternate figure, same basic idea

Berkeley FFS / UNIX FS

slide-5
SLIDE 5

CS 423: Operating Systems Design

Computers Circa 1991

5

■ Disk bandwidth is improving rapidly ■ Computers have more memory (up to 128 MB) ■ And, alas, disk seek times are … still dog slow! ■ The overhead was becoming larger now (as

the bandwidth is higher..)

■ What can we do to solve the problem? ■ Why not we always do sequential I/O?

slide-6
SLIDE 6

CS 423: Operating Systems Design

Thought Experiments

6

slide-7
SLIDE 7

CS 423: Operating Systems Design

Let’s do a design

7

slide-8
SLIDE 8

CS 423: Operating Systems Design

Debates

8

slide-9
SLIDE 9

CS 423: Operating Systems Design

Flash memory

9

■ No need for sequential writes

  • just need to find unused blocks

■ Can do 1->0 rewrites

  • Maintain a bitmap of used blocks at fixed block

■ Lots of complexity

  • Bits wear out, read disruption, etc
  • Who should deal with those complexity?
slide-10
SLIDE 10

CS 423: Operating Systems Design

Flash memory

10

■ No need for sequential writes

  • just need to find unused blocks

■ Can do 1->0 rewrites

  • Maintain a bitmap of used blocks at fixed block

■ Lots of complexity

  • Bits wear out, read disruption, etc
  • Who should deal with those complexity?