Goals for Today Learning Objective: Inspect Linux Disk Scheduling - - PowerPoint PPT Presentation

goals for today
SMART_READER_LITE
LIVE PREVIEW

Goals for Today Learning Objective: Inspect Linux Disk Scheduling - - PowerPoint PPT Presentation

Goals for Today Learning Objective: Inspect Linux Disk Scheduling Algorithms Survey concepts in File Systems Design Announcements, etc: Midterm scores posted on Compass (finally)! MP2 was due yesterday at 5am! MP3 is now


slide-1
SLIDE 1

CS 423: Operating Systems Design 1

Goals for Today

Reminder: Please put away devices at the start of class

  • Learning Objective:
  • Inspect Linux Disk Scheduling Algorithms
  • Survey concepts in File Systems Design
  • Announcements, etc:
  • Midterm scores posted on Compass (finally)!
  • MP2 was due yesterday at 5am!
  • MP3 is now available for download on Compass!
  • DUE APRIL 15th (19 days from now)… get started!!
  • MP2.5 (Extra Credit) releasing later today!
  • Next Class: MP3 Q&A, Midterm Debrief
slide-2
SLIDE 2

CS 423: Operating Systems Design

Professor Adam Bates

CS 423
 Operating System Design: File Systems

slide-3
SLIDE 3

CS 423: Operating Systems Design

Disk Scheduling

3

A: Track. B: Sector. C: Sector of Track. D: File

Disk Scheduling Decision — Given a series of access requests, on which track should the disk arm be placed next to maximize fairness, throughput, etc?

■ Which disk request is serviced first?

■ FCFS ■ Shortest seek time first ■ SCAN (Elevator) ■ C-SCAN (Circular SCAN)

slide-4
SLIDE 4

CS 423: Operating Systems Design

Linux I/O Schedulers

4

  • What disk (I/O) schedulers are available in Linux?
  • As of Linux 2.6.10, it is possible to change the IO

scheduler for a given block device on the fly!

  • How to enable a specific scheduler?
  • SCHEDNAME = Desired I/O scheduler
  • DEV = device name (e.g., sda)

$ cat /sys/block/sda/queue/scheduler noop deadline [cfq]

^ scheduler enabled on our VMs

$ echo SCHEDNAME > /sys/block/DEV/queue/scheduler

slide-5
SLIDE 5

CS 423: Operating Systems Design

Linux NOOP Scheduler

5

  • Insert all incoming I/O requests into a simple FIFO
  • Merges duplicate requests (results can be cached)
  • When would this be useful?
slide-6
SLIDE 6

CS 423: Operating Systems Design

Linux NOOP Scheduler

6

  • Insert all incoming I/O requests into a simple FIFO
  • Merges duplicate requests (results can be cached)
  • When would this be useful?
  • Solid State Drives! Avoids scheduling overhead
  • Scheduling is handled at a lower layer of the I/O

stack (e.g., RAID Controller, Network-Attached)

  • Host doesn’t actually know details of sector

positions (e.g., RAID controller)

slide-7
SLIDE 7

CS 423: Operating Systems Design

Linux Deadline Scheduler

7

  • Imposes a deadline on all I/O operations to prevent

starvation of requests

  • Maintains 4 queues:
  • 2 Sorted Queues (R, W), order by Sector
  • 2 Deadline Queues (R, W), order by Exp Time
  • Scheduling Decision:
  • Check if 1st request in deadline queue has expired.
  • Otherwise, serve request(s) from Sorted Queue.
  • Prioritizes reads (DL=500ms) over writes (DL=5s) .Why?
slide-8
SLIDE 8

CS 423: Operating Systems Design

Linux CFQ Scheduler

8

  • CFQ = Completely Fair Queueing!
  • Maintain per-process queues.
  • Allocate time slices for each queue to access the disk
  • I/O Priority dictates time slice, # requests per queue
  • Asynchronous requests handled separately — batched

together in priority queues

  • CFQ is often the default scheduler
slide-9
SLIDE 9

CS 423: Operating Systems Design

Linux Anticipatory Scheduler

9

  • Deceptive Idleness: A process appears to be finished

reading from disk, but is actually processing data. Another (nearby) request is coming soon!

  • Bad for synchronous read workloads because seek

time is increased.

  • Anticipatory Scheduling: Idle for a few milliseconds

after a read operation in anticipation of another close- by read request.

  • Deprecated — CFQ can approximate.
slide-10
SLIDE 10

CS 423: Operating Systems Design

Data Structures for a FS

10

Process control block

. . .

Open file pointer array Open file table (systemwide) Memory Inode

Disk inode

Data structures in a typical file system:

slide-11
SLIDE 11

CS 423: Operating Systems Design

Disk Layout for a FS

11

■ Data Structures: ■

File data blocks: File contents

File metadata: How to find file data blocks

Directories: File names pointing to file metadata

Free map: List of free disk blocks

Super block File metadata (i-node in Unix) File data blocks Boot block

Disk layout in a typical file system:

slide-12
SLIDE 12

CS 423: Operating Systems Design

Disk Layout for a FS

12

■ Superblock defines a file system

size of the file system

size of the file descriptor area

free list pointer, or pointer to bitmap

location of the file descriptor of the root directory

  • ther meta-data such as permission and various times

■ For reliability, replicate the superblock

Super block File metadata (i-node in Unix) File data blocks Boot block

Disk layout in a typical file system:

slide-13
SLIDE 13

CS 423: Operating Systems Design

Design Constraints

13

  • How can we allocate files efficiently?
  • For small files:
  • Small blocks for storage efficiency
  • Files used together should be stored together
  • For large files:
  • Contiguous allocation for sequential access
  • Efficient lookup for random access
  • Challenge: May not know at file creation where our

file will be small or large!!

slide-14
SLIDE 14

CS 423: Operating Systems Design

Design Challenges

14

  • Index structure
  • How do we locate the blocks of a file?
  • Index granularity
  • How much data per each index (i.e., block size)?
  • Free space
  • How do we find unused blocks on disk?
  • Locality
  • How do we preserve spatial locality?
  • Reliability
  • What if machine crashes in middle of a file system op?
slide-15
SLIDE 15

CS 423: Operating Systems Design

File Allocation

15

■ Contiguous ■ Non-contiguous (linked) ■ Tradeoffs?

slide-16
SLIDE 16

CS 423: Operating Systems Design

Contiguous Allocation

16

Request in advance for the size of the file

Search bit map or linked list to locate a space

File header

first sector in file

number of sectors

Pros

Fast sequential access

Easy random access

Cons

External fragmentation

Hard to grow files

slide-17
SLIDE 17

CS 423: Operating Systems Design

Linked Files

17

File header points to 1st block on disk

Each block points to next

Pros

Can grow files dynamically

Free list is similar to a file

Cons

random access: horrible

unreliable: losing a block means losing the rest File header null

. . .

slide-18
SLIDE 18

CS 423: Operating Systems Design

Linked Allocation

18

slide-19
SLIDE 19

CS 423: Operating Systems Design

Indexed File Allocation

19

Link full index blocks together using last entry.

slide-20
SLIDE 20

CS 423: Operating Systems Design

Multilevel Indexed Files

20

Multiple levels of index blocks

slide-21
SLIDE 21

CS 423: Operating Systems Design

UNIX FS Implementation

21 File position R/W Pointer to inode File position R/W Pointer to inode

Mode Link Count UID GID File size Times Address of first 10 disk blocks

Single Indirect Double Indirect

Triple Indirect inode Open file description Parent File descriptor table Child File descri ptor table Unrelated process File descriptor table

21

slide-22
SLIDE 22

CS 423: Operating Systems Design

Directory Structure Org.

22

■ maps symbolic names into logical file

names

■ search ■ create file ■ list directory ■ backup, archival, file migration

slide-23
SLIDE 23

CS 423: Operating Systems Design

Single-level Directory

23

slide-24
SLIDE 24

CS 423: Operating Systems Design

Tree-Structured Directories

24

■ arbitrary depth of directories ■ leaf nodes are files ■ interior nodes are directories ■ path name lists nodes to traverse to find

node

■ use absolute paths from root ■ use relative paths from current working

directory pointer

slide-25
SLIDE 25

CS 423: Operating Systems Design 25

Tree-Structured Directories

slide-26
SLIDE 26

CS 423: Operating Systems Design

Acyclic Graph Structured Dir.’s

26

slide-27
SLIDE 27

CS 423: Operating Systems Design

Symbolic Links

27

■ Symbolic links are different than regular links (often

called hard links). Created with ln -s

■ Can be thought of as a directory entry that points to

the name of another file.

■ Does not change link count for file

When original deleted, symbolic link remains

■ They exist because:

Hard links don’t work across file systems

Hard links only work for regular files, not directories

Hard link(s) Symbolic Link Contents of file Contents of file direct direct direct symlink