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. Singularity Details 2. Details of my Ext2 implementation 3. 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: 2. App 3. App --CH0-->SNS: 4. App

5. App --CH1-->Ext2Fs: 6. App 7. App --CH2-->Ext2Fs: 8. App 9. …

1. Inodes: Used on every access 2. Block Numbers: Very important for large files 3. Data Blocks: Naturally captures others  All use LRU replacement  Large files unusable without caching ◦ 8300X faster reading 350 MB file

 Athlon , 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 hurts, but not “too bad”  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