A New Design For FUSE File-Systems

At SCALE 10x a new FUSE implementation was presented that while still having the file-system in user-space, the kernel component is now responsible for more of the work.

Gordon Ross of Nexenta presented on his new FUSE implementation that implements in-kernel meta-data caching. With this caching in the kernel, less inefficient communication needs to happen between the kernel and the FUSE user-space. FUSE is what Linus Torvalds previously said was just for toys and misguided people. Among the many file-systems with FUSE variants are NTFS and ZFS.

Gordon's talk abstract for SCALE 10x reads, "FUSE (File-system in User Space) traditionally uses a very "thin" kernel module that communicates using a message passing interface to a user-level process that does all the interesting work. That approach forces a large number of very fine-grained requests for each high level file-system requests. An alternative to the traditional FUSE design is presented, where the kernel file-system module can do meta-data caching and some aggregation of requests, allowing the rendez-vous with the user-level helper process to be less frequent and more efficient. This allows the elimination of a significant portion of the work normally done by the user-level FUSE library. Also new in this approach is the use of illumos "door calls" (an efficient inter-process communication mechanism inherited from OpenSolaris) for communications between the in-kernel file-system module and the user-level FUSE service program. Experimental results from a prototype of this design are compared with the more traditional implementation, demonstrating some advantages of the new approach."

This former developer of Sun Microsystems based the improvements in part on his earlier smbfs work for Solaris. Right now he refers to this new implementation as being a "toy" and hasn't been pushed for upstream. Right now it's also just living in the Illumos world without any Linux-focused work.

With the reduced number of calls, the file I/O was reported to be about the same but path look-up and other operations were faster.