[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dazuko-devel] ClamFS and DazukoFS

From: John Ogness
Subject: [Dazuko-devel] ClamFS and DazukoFS
Date: Sat, 25 Aug 2007 16:31:54 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix)


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).


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:


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

John Ogness

Dazuko Maintainer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]