> I expect that FUSE offers more stability than the kernel's internal > interfaces.
OpenAFS has just added (complimentary) FUSE support, and it is indeed an attractive way of escaping from the interface churn of most open source kernels. What you sacrifice in order to do so does depend on the kernel you're using, and the way in which FUSE has been integrated. Developers for some platforms (NetBSD, for example) maintain that all new filesystems should be written in user space, and that any performance impact is negligible. Others have only accepted FUSE reluctantly, and put significant speed bumps in its way. There are some general architectural issues with FUSE - in particular, that it is very hard to avoid deadlocks when the page cache starts thrashing. In this case, the kernel has to evict pages without allocating any new ones - if page eviction requires a context switch to user space, then things become very tricky. There are games that can be played here in terms of pre-reserving pages, but I believe that many FUSE implementations have deadlock issues here. How efficient FUSE ends up being depends on how expensive user/kernel context switches are on your OS. In particular, if moving memory from user to kernel space is tricky, then FUSE will run slowly. If you're on a platform that makes this cheap, FUSE is will have far less overhead. FUSE also prevents Coda from doing it's current file operations trick, where it swaps the file operations from being Coda's to that of the backing cache, and so avoids the double-cache and memory caching problem that afflicts both fs-cache, and OpenAFS. If you moved to FUSE, you're going to end up with two page cache entries - one for "Coda" and the other for the backing FS. I'm not convinced that FUSE is any kind of magic pill. It's certainly a useful additional to the arsenal, but I don't think it can replace having a native filesystem for a wide variety of different platforms. Cheers, Simon.
