Hi, At the LinuxTag conference in Berlin last May, I had a chance to talk to several kernel developers about ideas, alternatives, and future directions for Dazuko. One of the ideas that was mentioned was to base DazukoFS on FUSE (Filesystem in Userspace).
http://fuse.sourceforge.net/ At first I wasn't very excited about this idea, but have since seen many advantages to FUSE. The biggest one being that it provides a common API for filesystems across different platforms (such as Linux, FreeBSD, NetBSD, MacOSX). Today I began looking into it more seriously and discovered ClamFS: http://clamfs.sourceforge.net/ This is a FUSE-based filesystem that is conceptually identical to what we have as a goal for DazukoFS. However, it has been "hard-coded" to work directly with the ClamAV scanner. I was quite excited to see this and quickly began hacking the ClamFS code to include the userspace version of Dazuko (system=dummyos). Within 2 hours I had a fully functional version of Dazuko based on ClamFS. :) Although initially exciting, the performance was quite disappointing. In fact, it is almost unbearable. It wasn't that the CPU was having to do a tremendous amount of work, but rather that the userspace processes didn't seem to be getting scheduled as often as they should be (or in a manner that is inefficient for what I needed). If the filesystem process itself would perform the file access control instead of communicating with an external process (via sockets), the performance would probably be more acceptable. (I'm sure the communication between filesystem process and file access control process could be optimized.) What does this all mean? It means that I am considering changing DazukoFS to be FUSE-based rather than a stackable filesytem in the kernel. My main motivation for this is that stackable filesystems are proving quite complex (especially if you want them to be able to stack on any kind of filesystem). A FUSE-based solution simplifies this greatly because the FUSE-based filesystem uses the common userspace API to access the underlying filesystems, which abstracts all details of the underlying filesystem. (I have yet to test if it would work correctly for "advanced" features such as SElinux, Capabilities, or more exotic filesystems such as the stackable ecryptfs.) Another nice advantage of using FUSE is that Dazuko would become a pure userspace project and not require any kernel files. This will make it easier to compile and make it independent of the constant changes within the Linux kernel. However, the biggest penalty (I fear) will be performance. But this is something that may be improved over time (especially since all FUSE-based filesystems are interested in such an improvement). I have not yet contacted the maintainer of ClamFS to ask if he is interested in abstracting ClamFS to provide a generic "stackable" FUSE-based filesystem. I am waiting to get more feedback. So please send me some feedback! I am also debating posting to the Linux Kernel mailing list to ask their opinions. Would they prefer that DazukoFS is a kernel module or FUSE-based? John Ogness -- Dazuko Maintainer _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
