EXT2C: Increasing Disk Reliability

1
EXT2C Increasing Disk Reliability

• Brian Pellin, Chloe Schulze
• CS736 Presentation
• May 3th, 2005

2
Introduction

• Problem Disks can fail silently, corrupting
  data
• (Partial) Solution Checksum the data to verify
  correctness before returning data to the user
• (This does not recover lost data, but at least
  the user knows the data is bad.)

3
Approach

• Implement checksumming within EXT2
• New read/write functions
• Wrap new functionality around existing functions
• New error code

4
Conclusion Summary

• Implemented working checksumming on top of EXT2
• Achieves added safety at the cost of additional
  overheads

5
Outline

• Fault Model
• EXT2C
• Performance
• Conclusions

6
Fault Model

• Fail Stop all or nothing
• No longer adequate for todays disk failures
• Partial Failure
• Latent sector errors
• Misdirection right data written to wrong
  location
• Phantom writes disk returns okay, but data was
  not written
• Malicious writes

7
Relating Fault Model to Implementation

• Partial Failure suggests
• Detection
• Notification
• Verification of data
• Backup or replication to avoid data loss

8
Outline

• Fault Model
• EXT2C
• Performance
• Conclusions

9
EXT2C

• EXT2 base file system
• Modifications
• Checksum file data
• New read/write functions to implement the
  checksumming
• New error code to notify user of data corruption

10
Checksums

• Checksum computed per block of a file
• One checksum file per inode
• Named for files inode number
• 20 bytes long (fixed length)
• Computed by the hash function SHA-1

11
Checksum Creation
foo.c
5 (Checksum file)
inode no. 5
0
0
20
4096
SHA-1
Block no. 1


12
Ext2C_file_read

• Normal file read
• Open checksum file
• Calculate blocks read
• For each block being read
• Read in block
• Compute checksum
• Read in old checksum
• Compare if not equal, return error
• Close checksum file
• Return result

13
Read Operation
Read 4000 bytes
2000
6000

• Read Data From File
• Read overlapping data block
• Read corresponding section of checksum file
• Hash Data and Compare with stored checksum
• Repeat for other blocks overlapped by read

Hash
Match or Failure
?
Checksum File
14
Ext2c_file_write

• Normal file write
• Calculate blocks changed
• Open checksum file
• For each changed block
• Read in block
• Compute checksum
• Write checksum to checksum file
• Close checksum file
• Return result of normal file write

15
Targeted Problems

• Detect
• Silently corrupted data
• Partially Detect
• Phantom writes
• Misdirection
• Malicious write

16
Outline

• Fault Model
• EXT2C
• Performance
• Conclusions

17
Correctness

• Able to run PostMark and additional benchmarks
  without encountering any errors
• Injected errors are detected and our error code
  is returned

18
EXT2 vs. EXT2C Test Outline

• Microbenchmarks
• Measure cold cache small reads/writes
• Warm Cache small reads
• Benchmarks capturing larger scale behavior
• PostMark
• Large sequential reads

19
Cold cache read/write Comparison

• We time the differences between ext2 and ext2c
  on
• Single block reads
• Single block writes
• 10 block reads
• 10 block writes

20
(No Transcript)
21
Warm cache comparison

• What overhead does ext2c add when data is cached
  in memory?

22
(No Transcript)
23
EXT2 vs. EXT2C Test Outline

• Microbenchmarks
• Measure cold cache small reads/writes
• Warm Cache small reads
• Benchmarks capturing larger scale behavior
• PostMark
• Large sequential reads

24
PostMark

• Benchmark crafted to simulate realistic small
  file workloads
• Intersperses read/write/append operations
• Measures throughput (transactions per second)

25
PostMark Results (Transactions per second)
26
Large Sequential Reads

• Desire
• Check summing costs will be amortized over long
  operations

27
(No Transcript)
28
Outline

• Fault Model
• EXT2C
• Performance
• Conclusions

29
Conclusions

• Benefit notification of data corruption, no
  longer mistake bad or wrong data for good data
• Cost overhead of checksum computation and extra
  I/O costs
• Throughput is halved on small file workloads
• Sequential I/O amortizes some overhead

30
Further Work

• Optimizations
• Open/close the checksum when the file is opened
  and closed
• Batch checksum creation at time of file system
  creation
• Ensuring that checksum data blocks are near file
  blocks to reduce seeking

31
References/Influences

• DesAutels, P. SHA 1 Secure Hash Algorithm.
  www.w3.org/PICS/DSig/SHA1_1_0.html 1997
• Patil, S., Kashyap, A., Sivanthanu, G., Zadok, E.
  I3FS An In-Kernel Integrity Checker and
  Intrusion Detection File System
  http//www.fsl.cs.sunysb.edu/docs/i3fs/i3fs.html
  2005.
• Prabhakaran, V., Agrawal, N., Bairavasundaram,
  L., Gunawi, H., Arpaci-Dusseau, A.,
  Arpaci-Dusseau, R. IRON File Systems. Draft
  2005
• Sivanthanu, G., Wright, C., Zadok, E. Enhancing
  File System Integrity Through Checksums.
  Technical Report FSL-04-04 2004.
• Stein, C., Howard, J., Seltzer, M. Unifying File
  System Protection, Proceedings of the 2001 USENIX
  Annual Technical Conference 2001
• Weinberg, G. Solaris Dynamic File System. Sun
  Microsystems Presentation