Ext2 On SingularityExt2 DefinedMicrosoft Research’s SingularityMy GoalsOverview of ResultsOutlineSingularityProgramming EnvironmentProcess ModelCommunication ChannelsDisk Read ExampleSlide 12Slide 13Slide 14Slide 15Slide 16Ext2 ImplementationRequired PiecesExt2 Client ManagerExt2 ControlExt2FsFile Read SequenceFile Read Sequence 2CachingResultsTestingSlide 27Slide 28Slide 29ConclusionQuestionsExtrasSlide 33Slide 34Slide 35Slide 36Scott FinleyUniversity of Wisconsin – MadisonCS 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 Details2. Details of my Ext2 implementation3. 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 ExHeapAppFile SystemDisk DriverExchange HeapEmpty BufferApplication send read request to file system◦File system owns the bufferAppFile SystemDisk DriverExchange HeapEmpty BufferFile system sends read request to driver◦Driver owns the bufferAppFile SystemDisk DriverExchange HeapEmpty BufferDriver fills buffer and replies to file systemAppFile SystemDisk DriverExchange HeapFull BufferFile system replies to applicationAppFile SystemDisk DriverExchange HeapFull BufferApplication consumes the bufferAppFile SystemDisk DriverExchange 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: <Bind,“/mnt/a/b.txt”,CH1>2.App<--CH0-- SNS: <Reparse, “/mnt”>3.App --CH0-->SNS: <Bind,”/mnt”,CH1>4.App<--CH0-- SNS: <AckBind>5. App --CH1-->Ext2Fs: <Bind,“/a/b.txt”,CH2>6. App<--CH1-- Ext2Fs: <AckBind>7. App --CH2-->Ext2Fs: <Read, Buff, BOff, FOff>8. App<--CH2-- Ext2Fs: <ReadAck, Buff>9. …1. Inodes: Used on every access2. Block Numbers: Very important for large files3. 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