Scott FinleyUniversity 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. Singularity Details2. Details of my Ext2 implementation3. 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

AppFile

SystemDisk

Driver

Exchange Heap

Empty Buffer

Application send read request to file system◦ File system owns the buffer

AppFile

SystemDisk

Driver

Exchange Heap

Empty Buffer

File system sends read request to driver◦ Driver owns the buffer

AppFile

SystemDisk

Driver

Exchange Heap

Empty Buffer

Driver fills buffer and replies to file system

AppFile

SystemDisk

Driver

Exchange Heap

Full Buffer

File system replies to application

AppFile

SystemDisk

Driver

Exchange Heap

Full Buffer

Application consumes the buffer

AppFile

SystemDisk

Driver

Exchange Heap

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

Client wants to read file “/mnt/a/b.txt”◦ Ext2 mounted at “/mnt”

1.App --CH0-->SNS: <Bind,“/mnt/a/b.txt”,CH1>2.App<--CH0-- SNS: <Reparse, “/mnt”>3.App --CH0-->SNS: <Bind,”/mnt”,CH1>4.App<--CH0-- SNS: <AckBind>

5. App --CH1-->Ext2Fs: <Bind,“/a/b.txt”,CH2>6. App<--CH1-- Ext2Fs: <AckBind>7. App --CH2-->Ext2Fs: <Read, Buff, BOff, FOff>8. App<--CH2-- Ext2Fs: <ReadAck, Buff>

9. …

1. Inodes: Used on every access2. Block Numbers: Very important for large

files3. 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

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