24: Lecture File Systems
David Lie
ECE344
University of Toronto
1
Outline
File Systems
Overview of file system
Disk Basics
File system design
Consistency and crash recovery
Sharing files
Unix file system
Disks
Disk scheduling algorithms
Redundancy in storage systems
ECE344: Operating Systems
2
Buffer Cache Management
File operations often access the same disk block
E.g., block containing contents of root (/) directory
Caching disk blocks in memory can reduce disk I/O
Traditionally block cache is called a buffer cache
Cache operations
Block lookup
If block in memory, returns data from buffer
Block miss
Read disk block into buffer, update buffer cache
Block flush
If buffer is modified, write it back to disk block
ECE344: Operating Systems
3
Buffer Cache Organization
Many blocks can be cached in memory (e.g., 1000s)
Need to lookup block in memory efficiently how?
Use a hash table
key
Device
Block #
Disk blocks in
memory
ECE344: Operating Systems
4
Buffer Cache Write Policy
When a block needs to be written, the corresponding buffer in
buffer cache is updated
When is the disk block updated?
Immediately (synchronously)
Write-through cache
Correct, but very slow
Later (asynchronously)
Write-back cache
Fast, but what if system crashes?
File system can become inconsistent
ECE344: Operating Systems
5
Lazy Buffer Writes
Example: say a file is created. Steps:
1. Inode allocated, free-space bitmap updated
2. Data block allocated, free-space bitmap updated
3. Inode updated to point to data block
4. Directory entry filled in
5. Directory entry updated to point to inode
What if we had done 4-5 before 1-3?
ECE344: Operating Systems
6
Crash Recovery
File update operations generally require several block write
operations
For example, deleting a Unix file involves two steps
1. Removing its directory entry
2. Marking inode as free, and marking block as free in free
map
Imagine that a crash occurs between these writes
FS data structures can be left in an invalid intermediate state
Synchronous writing of directory and inode blocks reduces
the problem but doesnt prevent it
ECE344: Operating Systems
7
Crash Recovery
Removing directory entry (1) is performed before marking blocks
as free (2) during delete
Suppose a crash occurs in between
There will be an orphaned inode, hence a storage leak
What if (2) is performed before (1)?
Crash occurs in between
Directory entry is a dangling pointer!
Could point to freed blocks or to a new file
More serious, hence Unix deletes in order (1)
ECE344: Operating Systems
8
Crash Recovery
In crash recovery, fixing system consistency is more important
than recovering data blocks:
If data blocks are corrupted on disk there is nothing you can
do
If file system is inconsistent then:
There can be data blocks that cant be found
There can be files whose data pointer point to the wrong
data blocks
There can be leaked blocks that cant be used
Fixing file system consistency tools (fsck, chkdisk)
Requires full a scan of the file system, rebuilding all pointer
structures from scratch as well as free list.
Dangling pointers are found, orphaned blocks are found
ECE344: Operating Systems
9
Speeding up recovery: Journaling File Systems
One way to speed up recovery is for the file system to keep a
journal of operations:
A separate part of the disk is dedicated to a circular log
called a journal
Operations are written to the journal first before committed to
the actual file system. Each journal entry is idempotent.
Example of journal entry might be:
Remove file x from directory inode y, then mark inode
of x as free.
On recovery, replay all journal entries in log.
ECE344: Operating Systems
10
Journaling File Systems
Only file system pointer and block allocation/deallocation data
stored journal:
Actual data blocks are not stored to conserve space
Recovery except for the last few operations is guaranteed:
If journal entry is incomplete, then recovery system knows
the operation never made it to disk: do nothing
If journal entry is complete, operation might have made it to
disk: since entries are idempotent, just redo them
All major file systems use journals:
Ext3/4, NTFS, ZFS (Sun), HFS (MacOS)
ECE344: Operating Systems
11
Sharing Files
Importance of file sharing should be clear
Issues
Concurrent access
What happens when threads read and write a file
simultaneously?
Protection
How should the OS ensure that only an authorized user
can access a file?
ECE344: Operating Systems
12
Concurrent Access
OS ensures sequential consistency for processes on the
same machine
Defined as saying that there exists a total order that all
processes perceive.
Total order means:
All processors see the same writes in the same order, i.e., if
a file block has value 1 and then a 2 is written, then no
process can read a 2 followed by a 1
Writes across different blocks also appear in the same order.
If one process sees block B modified after block A, than all
other processes must see the same order.
ECE344: Operating Systems
13
Concurrency
In network file systems sequential consistency is not guaranteed
for every operation:
Clients cache files locally for performance
For sequential consistency, an write by one client would
have to be updated to all other clients at the same time
Many network file systems offer open-to-close consistency
instead:
While open, modifications to a file are not shared with other
clients, other clients will may read old data before the open
On close, then all modification are made visible atomically
Guarantees are weak to maintain performance, files that are
open for a long time may have partial data flushed back to
file system server.
ECE344: Operating Systems
14
Concurrency
File systems do not guarantee atomicity automatically:
Processes doing multiple operations on a file may have
operations interleaved with those of other processes
Must use a locking mechanism outside of FS to guarantee
atomicity.
ECE344: Operating Systems
15