CPS 110 IO and file systems Landon Cox

CPS 110: I/O and file systems Landon Cox April 3, 2008

Virtual/physical interfaces Applications OS Hardware

Device independence ê Problem: many different disks ê Also interfaces, controllers, etc ê Each has their own custom interface ê How do we manage this diversity? ê Add an abstraction inside the OS

Device drivers Rest of OS OS file systems don’t have (can deal with device categories like network card, to know about specific devices video card, keyboard, mouse, etc. ) Device drivers Millions of specific devices Make life easier for the OS (still run in the kernel)

Device drivers Rest of OS (can deal with device categories like network card, video card, keyboard, mouse, etc. ) Device drivers 70% of Linux kernel code 120, 000 driver versions for XP 85% of XP failures Millions of specific devices Drivers in Windows vs Mac? In Vista, many drivers run in user space. Why?

Crashes in Vista

Other abstractions we’ve seen ê Abstractions simplify things for their users ê Threads ê Programmers don’t have to worry about sharing the CPU ê Address spaces ê Applications don’t have to worry about sharing phys mem ê TCP ê Network code needn’t worry about unreliable network ê Device drivers ê Parts of OS don’t have to worry about device

Virtual/physical interfaces Applications OS Hardware

Block-oriented vs byteoriented ê Disks are accessed in terms of blocks ê Also called sectors ê Similar idea to memory pages ê E. g. 4 KB chunks of data ê Programs deal with bytes ê E. g. change ‘J’ in “Jello world” to ‘H’

Block-oriented vs byteoriented ê How to read less than a block? ê Read entire block ê Return the right portion ê How to write less than a block? ê Read entire block ê Modify the right portion ê Write out entire block ê Nothing analogous to byte-grained load/store ê Flash devices are even more complicated

Disk geometry

Surface organized into tracks

Parallel tracks form cylinders

Tracks broken up into sectors

Disk head position

Rotation is counter-clockwise

About to read a sector

After reading blue sector

Red request scheduled next After BLUE read

Seek to red’s track After BLUE read SEEK Seek for RED

Wait for red sector to reach head After BLUE read SEEK Seek for RED Rotational latency ROTATE

Read red sector After BLUE read SEEK Seek for RED Rotational latency ROTATE After RED read

To access a disk 1. Queue (wait for disk to be free) ê 0 -infinity ms 2. Position disk head and arm ê Seek + rotation ê 0 -12 ms ê Pure overhead 3. Access disk data ê Size/transfer rate (e. g. 49 MB/s) ê Useful work

Goals for optimizing performance ê Disk is really slow ê In the time to do a disk seek (~6 ms) ê 3 GHz processor executes 18 million cycles! ê Efficiency = transfer time/(positioning+transfer time) a) Best option is to eliminate disk I/O (caching) b) Then try to minimize positioning time (seeks) c) Then try to amortize positioning overhead

Goals for optimizing performance ê For each re-positioning, transfer a lot of data ê True of any storage device ê Particularly true for disks ê Fast transfer rate, long positioning time ê For Seagate Barracuda 1181677 LW ê Can get 50% efficiency ê Transfer 6*49 = 294 KB after 6 ms seek

How to reduce positioning time ê Can optimize when writing to disk ê Try to reduce future positioning time ê Put items together that will be accessed at the same time ê How can we know this? ê Use general usage patterns ê Blocks in same files usually accessed together ê Files in a directory tend to be accessed together ê Files tend to be accessed with the containing directory ê Learn from past accesses to specific data ê Can also optimize when reading from disk

Disk scheduling ê Idea ê Take a bunch of accesses ê Re-order them to reduce seek time ê Kind of like traveling salesman problem ê Can do this either in OS or on disk ê OS knows more about the requests ê Disk knows more about disk geometry

First-come, first-served (FCFS) ê E. g. start at track 53 ê Other queued requests ê 98, 183, 37, 122, 14, 124, 65, 67 ê Total head movement ê 640 tracks ê Average 80 tracks per seek

Shortest seek time first (SSTF) ê E. g. start at track 53 ê Other requests ê 53, 65, 67, 37, 14, 98, 122, 124, 183 ê Total head movement ê 236 tracks ê Average 30 tracks per seek Any problems with this? Starvation

Course administration ê Project 3 ê Out on Tuesday (April 8 th) ê Due two weeks later (April 22 nd) ê Other upcoming dates ê Final lecture on April 22 nd ê Last day of classes is April 23 rd ê Final exam will be Friday, May 2, 7 p-10 p ê (Amre will proctor)

Virtual/physical interfaces Applications OS Hardware

File systems ê What is a file system? ê OS abstraction that makes disks easy to use ê File system issues 1. How to map file space onto disk space ê Structure and allocation: like mem management 2. How to use names instead of sectors ê Naming and directories: not like memory ê But very similar to DNS

Intro to file system structure ê Overall question: ê How do we organize things on disk? ê Really a data structure question ê What data structures do we use on disk?

Intro to file system structure ê Need an initial object to get things going ê In file systems, this is a file header ê Unix: this is called an inode (indexed node) ê File header contains info about the file ê Size, owner, access permissions ê Last modification date ê Many ways to organize headers on disk ê Use actual usage patterns to make good decisions

File system usage patterns 1. 80% of file accesses are reads (20% writes) ê Ok to save on reads, even if it hurts writes 2. Most file accesses are sequential and full ê Form of spatial locality ê Put sequential blocks next to each other ê Can pre-fetch blocks next to each other 3. Most files are small 4. Most bytes are consumed by large files

1) Contiguous allocation ê Store a file in one contiguous segment ê Sometimes called an “extent” ê Reserve space in advance of writing it ê User could declare in advance ê If grows larger, move it to a place that fits

1) Contiguous allocation ê File header contains ê Starting location (block #) of file ê File size (# of blocks) ê Other info (modification times, permissions) ê Exactly like base and bounds memory

1) Contiguous allocation ê Pros ê Fast sequential access ê Easy random access ê Cons ê External fragmentation ê Internal fragmentation ê Hard to grow files

2) Indexed files ê File header File block # Disk block # 0 18 1 50 2 8 3 15 ê Looks a lot like a page table

2) Indexed files ê Pros ê Easy to grow (don’t have to reserve in advance) ê Easy random access ê Cons ê How to grow beyond index size? ê Sequential access may be slow. Why? ê May have to seek after each block read Why wasn’t sequential access a problem with page tables? Memory doesn’t have seek times.

2) Indexed files ê Pros ê Easy to grow (don’t have to reserve in advance) ê Easy random access ê Cons ê How to grow beyond index size? ê Lots of seeks for sequential access How to reduce seeks for sequential access? Don’t want to pre-allocate blocks.

2) Indexed files ê Pros ê Easy to grow (don’t have to reserve in advance) ê Easy random access ê Cons ê How to grow beyond index size? ê Lots of seeks for sequential access How to reduce seeks for sequential access? When you allocate a new block, choose one near the one that precedes it. E. g. blocks in the same cylinder.

What about large files? ê Could just assume it will be really large ê Problem? ê Wastes space in header if file is small ê Max file size is 4 GB ê File block is 4 KB 1 million pointers ê 4 MB header for 4 byte pointers ê Remember most files are small ê 10, 000 small files 40 GB of headers

What about large files? ê Could use a larger block size ê Problem? ê Internal fragmentation (most files are small) ê Solution ê Use a more sophisticated data structure

3) Multi-level indexed files ê Think of indexed files as a shallow tree ê Instead could have a multi-level tree ê Level 1 points to level 2 nodes ê Level 2 points to level 3 nodes ê Gives us big files without wasteful headers

3) Multi-level indexed files Level 1 Level 2 Level 3 (data) How many access to read one block of data? 3 (one for each level)

3) Multi-level indexed files Level 1 Level 2 Level 3 (data) How to improve performance? Caching.

3) Multi-level indexed files ê To reduce number of disk accesses ê Cache level 1 and level 2 nodes ê Often a useful combination ê Indirection for flexibility ê Caching to speed up indirection ê Can cache lots of small pointers ê Where else have we seen this strategy? ê DNS

3) Multi-level indexed files Level 1 Level 2 Level 3 What about small files (i. e. most files)?

3) Multi-level indexed files Use a non-uniform tree

3) Multi-level indexed files ê Pros ê Simple ê Files can easily expand ê Small files don’t pay the full overhead ê Cons ê Large files need lots of indirect blocks (slow) ê Could have lots of seeks for sequential access

Virtual/physical interfaces Applications OS Hardware

Multiple updates and reliability ê Reliability is only an issue in file systems ê Don’t care about losing address space after crash ê Your files shouldn’t disappear after a crash ê Files should be permanent ê Multi-step updates cause problems ê Can crash in the middle

Multi-step updates ê Transfer $100 from Melissa’s account to mine 1. Deduct $100 from Melissa’s account 2. Add $100 to my account ê Crash between 1 and 2, we lose $100

Multiple updates and reliability ê This is a well known, undergrad OS-level problem ê No modern OS would make this mistake, right? ê Video evidence suggests otherwise ê ê Directory with 3 files Want to move them to external drive Drive “fails” during move Don’t want to lose data due to failure ê Roll film …

The lesson? 1. Building an OS is hard. 2. OSes are software, not religions (one is not morally superior to another) 3. “Fanboys are stupid, but you are not. ” (Anil Dash, dashes. com/anil)