Scott Finley
University of Wisconsin – Madison
CS 736 Project


Basic, default Linux file system
Almost exactly the same as FFS
◦ Disk broken into “block groups”
◦ Super-block, inode/block bitmaps, etc.




New from the ground up
Reliability as #1 goal
Reevaluate conventional OS structure
Leverage advances of the last 20 years
◦ Languages and compilers
◦ Static analysis of whole system




Implement Ext2 on Singularity
Focus on read support with caching
Investigate how Singularity design impact FS
integration
Investigate performance implications

I have a Ext2 “working” on Singularity
◦ Reading fully supported
◦ Caching improves performance!
◦ Limited write support

Singularity design
◦ Garbage collection hurts performance
◦ Reliability is good: I couldn’t crash it.
1.
2.
3.
Singularity Details
Details of my Ext2 implementation
Results

Everything is written in C#
◦ Small pieces of kernel (< 5%) in assembly and C++
as needed


Kernel and processes are garbage collected
No virtual machine
◦ Compiled to native code

Very aggressive optimizing compiler


Singularity is a micro kernel
Everything else is a SIP
◦ “Software Isolated Process”

No hardware based memory isolation
◦ SIP “Object Space” isolation guaranteed by static
analysis and safe language (C#)
◦ Context switches are much faster





All SIP communication is via message
channels
No shared memory
Messages and data passed via Exchange Heap
Object ownership is tracked
Zero copy data passing via pointers

Application creates buffer in ExHeap
App
File System
Empty
Buffer
Exchange Heap
Disk Driver

Application send read request to file system
◦ File system owns the buffer
App
File System
Empty
Buffer
Exchange Heap
Disk Driver

File system sends read request to driver
◦ Driver owns the buffer
App
File System
Empty
Buffer
Exchange Heap
Disk Driver

Driver fills buffer and replies to file system
App
File System
Full Buffer
Exchange Heap
Disk Driver

File system replies to application
App
File System
Full Buffer
Exchange Heap
Disk Driver

Application consumes the buffer
App
File System
Exchange Heap
Disk Driver




Ext2Control: Command line application
Ext2ClientManager: Manages mount points
Ext2FS: Core file system functionality
Ext2Contracts: Defines communication





System service (SIP) launched at boot
Accessible at known location in /dev directory
Does “Ext2 stuff”
Operates on Ext2 volumes and mount points
Exports “Mount” and “Unmount”
◦ Would also provide “Format” if implemented

300 lines of code




Command line application
Allows Ext2 Client Manger interface access
Not used by other applications
500 lines of code


Core Ext2 file system.
Separate instance (SIP) for each mount point.
◦ Exports “Directory Service Provider” interface

Clients open files and directories by attaching
a communication channel
◦ Internally paired with an Inode.


Reads implemented, Writes in progress
2400 Lines of code

1.
2.
3.
4.
Client wants to read file “/mnt/a/b.txt”
◦ Ext2 mounted at “/mnt”
App --CH0-->SNS: <Bind,“/mnt/a/b.txt”,CH1>
App<--CH0-- SNS: <Reparse, “/mnt”>
App --CH0-->SNS: <Bind,”/mnt”,CH1>
App<--CH0-- SNS: <AckBind>
8.
App --CH1-->Ext2Fs:
App<--CH1-- Ext2Fs:
App --CH2-->Ext2Fs:
App<--CH2-- Ext2Fs:
9.
…
5.
6.
7.
<Bind,“/a/b.txt”,CH2>
<AckBind>
<Read, Buff, BOff, FOff>
<ReadAck, Buff>
1.
2.
3.


Inodes: Used on every access
Block Numbers: Very important for large files
Data Blocks: Naturally captures others
All use LRU replacement
Large files unusable without caching
◦ 8300X faster reading 350 MB file






Athlon 64 3200, 1 GB RAM
Disk: 120GB, 7200 RPM, 2 MB buffer, PATA
Measured sequential reads
Varied read buffer size from 4 KB to 96 MB
Timed each request
File sizes ranged from 13 MB to 350 MB
350MB File Sequential Read
35
30
Read Speed (MB/S)
25
Linux
Average
4 KB
20
8 KB
16 KB
64 KB
15
256 KB
1 MB
8 MB
10
64 MB
96 MB
Cold
5
0
2,048
8,192
32,768
131,072
524,288
2,097,152
Buffer Size (Bytes)
8,388,608
33,554,432
134,217,728
Request Service Time for reads of 350 MB file with 16 KB buffers
35
Request Service Time (ms)
30
25
20
15
10
5
0
Time
200 Sequential 16 KB Buffer Reads of 350 MB
File
35
30
Read Speed (MB/s)
25
20
15
10
5
0
Time

Linux is faster
◦ Not clear that this is fundamental

Performance is not horrible
◦ “Good enough” objective met
◦ Garbage collection overhead < 0.1%

Not sensitive to file size



System programming in a modern language
System programming with no crashes
Micro kernel is feasible
◦ Hurts feature integration: mmap, cache sharing
◦ Clean, simple interfaces
13 MB File Sequential Read
35
30
Read Speed (MB/S)
25
Linux
Average
4 KB
20
8 KB
16 KB
64 KB
15
256 KB
1 MB
8 MB
10
64 MB
96 MB
Cold
5
0
2,048
8,192
32,768
131,072
524,288
2,097,152
Buffer Size (Bytes)
8,388,608
33,554,432
134,217,728
64 KB Buffer Reads of 350 MB File
35
30
Read Speed (MB/s)
25
20
15
10
5
0
Time
64 MB Buffer Reads of 350 MB File
30
Read Speed (MB/s)
25
20
15
10
5
0
Time
Average Sequential Read Speeds
30
Read Speed (MB/s)
25
20
15
13 MB File
350 MB File
10
5
0
2,048
8,192
32,768
131,072
524,288
2,097,152
Buffer Size
8,388,608
33,554,432 134,217,728