1. Scott Finley University of Wisconsin – Madison CS 736 Project

2.  Basic, default Linux file system  Almost exactly the same as FFS ◦ Disk broken into “block groups” ◦ Super-block, inode/block bitmaps, etc.

3.  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

4.  Implement Ext2 on Singularity  Focus on read support with caching  Investigate how Singularity design impact FS integration  Investigate performance implications

5.  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.

6. 1. Singularity Details 2. Details of my Ext2 implementation 3. Results

8.  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

9.  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

10.  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

11.  Application creates buffer in ExHeap AppFile SystemDisk Driver Exchange Heap Empty Buffer

12.  Application send read request to file system ◦ File system owns the buffer AppFile SystemDisk Driver Exchange Heap Empty Buffer

13.  File system sends read request to driver ◦ Driver owns the buffer AppFile SystemDisk Driver Exchange Heap Empty Buffer

14.  Driver fills buffer and replies to file system AppFile SystemDisk Driver Exchange Heap Full Buffer

15.  File system replies to application AppFile SystemDisk Driver Exchange Heap Full Buffer

16.  Application consumes the buffer AppFile SystemDisk Driver Exchange Heap

18.  Ext2Control: Command line application  Ext2ClientManager: Manages mount points  Ext2FS: Core file system functionality  Ext2Contracts: Defines communication

19.  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

20.  Command line application  Allows Ext2 Client Manger interface access  Not used by other applications  500 lines of code

21.  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

22.  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

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

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

26.  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

29.  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

30.  System programming in a modern language  System programming with no crashes  Micro kernel is feasible ◦ Hurts feature integration: mmap, cache sharing ◦ Clean, simple interfaces