Andrew Morton wrote:
> Miklos Szeredi <[email protected]> wrote:
>>
>>??Well,?there?doesn't?seem?to?be?a?great?rush?to?include?FUSE?in?the
>>??kernel.??Maybe?they?just?don't?realize?what?they?are?missing?out?on?;)
>
>heh.??What?userspace?filesystems?have?thus-far?been?developed,?and?what
> are people using them for?
There's been sort of an increasing hype around userspace filesystems
during last years (and exponentially during last months), as a result
we have lufs, plasticfs, fuse and some other implementation of a
kernel-userspace bridge for filesystems, but also many more or less
interesting (depending on one's point of view) ongoing free software
projects using those, which mainly cover interfacing to "strange" or
proprietary-protocol hardware devices as if they where filesystems,
access to remote data as if it was local, or new filesystem concepts
such as filesystems that have relational databases as helpers.
Apart from projects "officially" using fuse, listed at
http://fuse.sourceforge.net/filesystems.htm
I know of another interface to proprietary protocol mp3 players where
they are actively developing a filesystem interface using fuse and
libusb in ocaml - resulting in a quick and robust prototype written in
a few spare time.
In defense of fuse itself I can mention the ease of use, both of the C
library and of interfaces for other languages, its robustness and its
completeness w.r.t. features (e.g. extended attributes, multithreading
and access from multiple users and serving files "virtually" owned by
different users).
Said this, and after commenting that I am nobody but yet another
developer of yet another "new filesystem concept", I think that besides
useful filesystems already developed, something good will come out of
all these people experimenting with filesystems, databases, indexing
systems and so on, but that if we want to take the good out of this
all, even for already existing projects like sshfs or gphoto2-fuse-fs,
we need fuse to be distributed in the kernel so that people is
encouraged to try them in their everyday life.
I will quote an e-mail from a researcher in a group who is implementing
a particular filesystem and has ended up resorting to plasticfs (which
uses the LD_PRELOAD trick - not quite satisfying but it does not
require kernel patching) saying:
> Most of the problem I have [...] will still be in a better
> MLFUSE, which is that it requires to modify the kernel by loading a
> module (which is often tied to one particular version of Linux which
> means that it is tedious to maintain such module), and users hate
> that.
bye
Vincenzo Ciancia
ciancia at di unipi it
vincenzo_ml at yahoo it
Hi,
On 13 January 2005 00:33, you wrote:
> a particular filesystem and has ended up resorting to plasticfs (which
> uses the LD_PRELOAD trick - not quite satisfying but it does not
>
> require kernel patching) saying:
> > Most of the problem I have [...] will still be in a better
> > MLFUSE, which is that it requires to modify the kernel by loading a
> > module (which is often tied to one particular version of Linux which
> > means that it is tedious to maintain such module), and users hate
> > that.
Can't agree more. I don't want to release my fuse-based SMB-connector (smb
kioslave/gnome-vfs replacement :-) for exactly this reason - having released
some projects earlier , I can't afford (in terms of time) to answer emails
asking how to install fuse , where to grab it and which version, how to build
etc, so I'm eagerly awaiting when fuse will be merged and I could point to
kernel.org and required kernel version...
Right now I think -mm tree will be a good starting point to instantly increase
fuse testing base to iron out possible glitches and to ensure official
acceptance.
--
Managing your Territory since the dawn of times ...