1 / 37

Ext2 On Singularity

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.

raphael-powell
Download Presentation

Ext2 On Singularity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. Outline • Singularity Details • Details of my Ext2 implementation • Results

  7. Singularity

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

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

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

  11. Disk Read Example • Application creates buffer in ExHeap App File System Disk Driver Exchange Heap Empty Buffer

  12. Disk Read Example • Application send read request to file system • File system owns the buffer App File System Disk Driver Exchange Heap Empty Buffer

  13. Disk Read Example • File system sends read request to driver • Driver owns the buffer App File System Disk Driver Exchange Heap Empty Buffer

  14. Disk Read Example • Driver fills buffer and replies to file system App File System Disk Driver Exchange Heap Full Buffer

  15. Disk Read Example • File system replies to application App File System Disk Driver Exchange Heap Full Buffer

  16. Disk Read Example • Application consumes the buffer App File System Disk Driver Exchange Heap

  17. Ext2 Implementation

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

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

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

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

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

  23. 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> • …

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

  25. Results

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

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

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

  29. Questions

  30. Extras

More Related