 I’ve built two FUSE file systems (I’ve already made all of the mistakes):  OLFS:  NOFS:  Have built several hobby and small operating systems  Worked at Purdue University on virtual memory in the Linux kernel and taught the undergraduate Operating Systems labs.  Have worked professionally on networked, embedded, and distributed systems for 5+ years (I’ve come to understand what not to do).

 Implemented as a Linux Kernel Module.  Re-routes calls to the VFS layer from user programs to a special file /dev/fuse  A userland program can then use libfuse to read and write /dev/fuse  Calls exposed by libfuse are meant to mimic (mostly) those available to userland programs in UNIX

 What language do I develop in?  C#, Python, Perl, C, C++,  any language that can call in to C  Stateful vs. Stateless  FUSE file systems are a service.  Consider complexity and performance.  Very important question for network and distributed file systems (cache coherence problem)  Access to resources  Each access to a disc or network can involve context switches and affect performance

 Good working knowledge of C programming in UNIX and associated file manipulation methods (read, write, lstat, lseek, etc..)  Good understanding of locking and concurrency.  A general understanding of operating systems topics.  Good unit testing and debugging skills.  Patience

 Find the FUSE framework to be too complex or difficult? Don’t want to invest time in learning systems programming?  Try NOFS!