Ext2 On Singularity
This project outlines the implementation of the Ext2 file system on Microsoft Research’s Singularity OS, focusing on reliability and performance. Singularity, designed as a microkernel architecture, re-evaluates traditional OS structures by employing safe languages like C#. The implementation targets read support with caching to enhance performance while investigating the integration impacts and performance implications stemming from Singularity’s design. Results indicate suitable read capabilities and improved performance, although write support remains limited. This study gains deeper insights into the challenges of system programming in a modern language.
Ext2 On Singularity
E N D
Presentation Transcript
Ext2 On Singularity Scott Finley University of Wisconsin – Madison CS 736 Project
Ext2 Defined • Basic, default Linux file system • Almost exactly the same as FFS • Disk broken into “block groups” • Super-block, inode/block bitmaps, etc.
Microsoft Research’s Singularity • 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
My Goals • Implement Ext2 on Singularity • Focus on read support with caching • Investigate how Singularity design impact FS integration • Investigate performance implications
Overview of Results • 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.
Outline • Singularity Details • Details of my Ext2 implementation • Results
Programming Environment • 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
Process Model • 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
Communication Channels • 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
Disk Read Example • Application creates buffer in ExHeap App File System Disk Driver Exchange Heap Empty Buffer
Disk Read Example • Application send read request to file system • File system owns the buffer App File System Disk Driver Exchange Heap Empty Buffer
Disk Read Example • File system sends read request to driver • Driver owns the buffer App File System Disk Driver Exchange Heap Empty Buffer
Disk Read Example • Driver fills buffer and replies to file system App File System Disk Driver Exchange Heap Full Buffer
Disk Read Example • File system replies to application App File System Disk Driver Exchange Heap Full Buffer
Disk Read Example • Application consumes the buffer App File System Disk Driver Exchange Heap
Required Pieces • Ext2Control: Command line application • Ext2ClientManager: Manages mount points • Ext2FS: Core file system functionality • Ext2Contracts: Defines communication
Ext2 Client Manager • 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
Ext2 Control • Command line application • Allows Ext2 Client Manger interface access • Not used by other applications • 500 lines of code
Ext2Fs • 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
File Read Sequence • 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>
File Read Sequence 2 • App --CH1-->Ext2Fs: <Bind,“/a/b.txt”,CH2> • App<--CH1-- Ext2Fs: <AckBind> • App --CH2-->Ext2Fs: <Read, Buff, BOff, FOff> • App<--CH2-- Ext2Fs: <ReadAck, Buff> • …
Caching • 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
Testing • 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
Results • 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
Conclusion • System programming in a modern language • System programming with no crashes • Micro kernel is feasible • Hurts feature integration: mmap, cache sharing • Clean, simple interfaces
