Inicio

The reason for the
userspace stuff: there are operations only suited for userspace
(cryptography for example) and implementing them in kernel would be
bloat.

The reason for the kernel
stuff: I think it’s important to keep the file system access point at
the lowest level in order to allow all the applications to use it.
Consider KDE: it implements its own virtual file system, a great one,
but only KDE applications can take advantage of it. So does GNOME, MC
and others. Suddenly we have lots of overlapping userspace file
system implementations, a real waste…

Communication between the
kernel module and the daemon is done through UNIX domain sockets.
This makes LUFS best suited for networked file systems, where this
indirection overhead (userspace <-> kernel <-> userspace)
is small compared to the speed penalty due to the network itself.

LUFS can be regarded as
doing the same job as the VFS (virtual file system switch) in the
kernel: it is a switch, distributing the file system calls to its
supported file systems. With a big difference: LUFS file systems are
implemented in userspace. This would be a drawback for local file
systems where the access speed is important, but proves to be a huge
advantage for networked file systems where the userland
flexibility is most important.

This flexibility allowed
for implementation of SSHFS for example, in a pretty straightforward
manner, using the already existing openssh
infrastructure. Lots of other “exotic” file systems are in the
planning phase: socketfs, httpfs, webdavfs, freenetfs, etc. Just
imagine mounting a freenet file system and accessing all the goodies
as they were local…