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 File System App Empty Buffer Exchange Heap Disk Driver Application send read request to file system File system owns the buffer File System App Empty Buffer Exchange Heap Disk Driver File system sends read request to driver Driver owns the buffer File System App Empty Buffer Exchange Heap Disk Driver Driver fills buffer and replies to file system File System App Full Buffer Exchange Heap Disk Driver File system replies to application File System App 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 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 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 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