Re: [fuse-devel] Merging?

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> > How goes the attempt to get FUSE merged into Andrew or Linus' tree?
> > I saw that an attempt was made about three weeks ago on the LKML.
> 
> I made some changes to the kernel code since the last submission
> (related to being able to interrupt requests), and some problems still
> need to be ironed out.  Then I'll submit again, hopefully this time
> with more success :)

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

So if any of you would like to support this motion, you can mail the
linux-kernel list and maybe Linus and Andrew, to generate a little
discussion on why (or why not) inclusion is a good idea.

Thanks,
Miklos

Re: [fuse-devel] Merging?

[Diego Calleja]

El Wed, 12 Jan 2005 14:49:35 +0100 Miklos Szeredi <miklos@szeredi.hu> escribió:


> So if any of you would like to support this motion, you can mail the
> linux-kernel list and maybe Linus and Andrew, to generate a little
> discussion on why (or why not) inclusion is a good idea.


Personally I think it's cool for "desktops" and other reasons because:

-It could replace gnome-vfs AND kioslaves by a more generic solution that works
 for all environments

-You could implement several "not-performance-critical" filesystems (fat,
 isofs) with FUSE to avoid possible security issues. Give that nowadays 
 usb sticks and cd/dvds are so common it'd be possible to modify a filesystem
 on purpose to crash the kernel if a bug were found in those filesytems. With
 FUSE that posibility decreases.

-Since you can use other programming languages, I suposse it'd be easier for
 people to write support for weird filesystems.

-Better for kernel (less code to maintain given a big number of filesystems)
 and less pressure for VFS developers when making big changes to the VFS.

-Possibility to write stupid filesystems like "gmailfs".
 

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> -You could implement several "not-performance-critical" filesystems (fat,
>  isofs) with FUSE to avoid possible security issues. Give that nowadays 
>  usb sticks and cd/dvds are so common it'd be possible to modify a filesystem
>  on purpose to crash the kernel if a bug were found in those filesytems. With
>  FUSE that posibility decreases.

One of my pet ideas, is a userspace loopback mounter, which would use
UML to actually mount an image, and export the resulting filesystem
through FUSE to the host.

Brilliant isn't it?

Miklos

Re: [fuse-devel] Merging?

[Florian Schanda]

On Wednesday 12 January 2005 14:31, Diego Calleja wrote:
> -It could replace gnome-vfs AND kioslaves by a more generic solution that
> works for all environments

kioslaves such as camera, smb, etc.. are obvious to replace (and this has 
already happened from what I can see), and I think are a good idea. We have a 
single mountpoint for these things, for example:
 /camera/mycamera/picture1.png
 /smb/workgroup/computer/share/file.blah

How would you go about replacing a kioslaves which operate "somewhere in the 
middle" (i dunno the correct technical term) such as tar? In other words how 
would tar:/home/foo/bar.tar.bz2/baz/picture.png work with a FUSE (so 
reiserfs4 is not a valid answer to this question) filesystem?

Just some thoughts,

 Florian

Re: [fuse-devel] Merging?

[Dobrica Pavlinusic]

On Wed, Jan 12, 2005 at 03:31:31PM +0100, Diego Calleja wrote:
> El Wed, 12 Jan 2005 14:49:35 +0100 Miklos Szeredi <miklos@szeredi.hu> escribió:
> > 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 ;)
> >
> > So if any of you would like to support this motion, you can mail the
> > linux-kernel list and maybe Linus and Andrew, to generate a little
> > discussion on why (or why not) inclusion is a good idea.
> 
> -Possibility to write stupid filesystems like "gmailfs".

Not to mention Fuse::DBI which allows you to mount relational database
as a file-system. Imagine editing templates from your CMS with vi. Joy,
right?

Back to serious notes, having ability to write filesystems in user-space
is something that micro kernels (like HURD or plan9) had for a long time
and it's extremely useful if file-system semantic is mappable to problem
at hand.

That would also help reduce kernel bloat because you could write
something like umsdos in user-space where it belongs in first place.

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin@rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

Re: [fuse-devel] Merging?

[Andrew Morton]

Miklos Szeredi <miklos@szeredi.hu> 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?

Re: [fuse-devel] Merging?

[Erik Hensema]

Andrew Morton (akpm@osdl.org) wrote:
> Miklos Szeredi <miklos@szeredi.hu> 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?

I was using siefs, to mount the fs of my Siemens mobile phone
(via serial cable). However it doesn't seem to work with the
current fuse anymore.

-- 
Erik Hensema <erik@hensema.net>

Re: [fuse-devel] Merging?

[Pavel Machek]

Hi!

> > > How goes the attempt to get FUSE merged into Andrew or Linus' tree?
> > > I saw that an attempt was made about three weeks ago on the LKML.
> > 
> > I made some changes to the kernel code since the last submission
> > (related to being able to interrupt requests), and some problems still
> > need to be ironed out.  Then I'll submit again, hopefully this time
> > with more success :)
> 
> 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 ;)
> 
> So if any of you would like to support this motion, you can mail the
> linux-kernel list and maybe Linus and Andrew, to generate a little
> discussion on why (or why not) inclusion is a good idea.

I like fuse, but I do not think Linus and Akpm have enough mails already. Getting it merged to some distribution might
do the trick....

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> I was using siefs, to mount the fs of my Siemens mobile phone
> (via serial cable). However it doesn't seem to work with the
> current fuse anymore.

The following patch makes it compile with FUSE 2.2-pre3 too.  You need
to run autoreconf after patching.

Not tested, since I don't have a Siemens phone.

Miklos

diff -ru siefs-0.4.orig/configure.in siefs-0.4/configure.in
--- siefs-0.4.orig/configure.in	2004-08-13 08:39:07.000000000 +0200
+++ siefs-0.4/configure.in	2005-01-12 20:40:20.000000000 +0100
@@ -39,14 +39,6 @@
 ])
 fi
 
-if ! grep -q '\(\*release\)' $fuseinst/include/fuse.h ; then
-	AC_MSG_RESULT([old])
-	AC_MSG_ERROR([
-*** You need fuse version 1.0 or later.
-*** Please go to http://sourceforge.net/projects/avf
-*** and download the latest version
-])
-fi
 AC_MSG_RESULT(${fuseinst})
 AC_SUBST(fuseinst)
 
diff -ru siefs-0.4.orig/siefs/Makefile.am siefs-0.4/siefs/Makefile.am
--- siefs-0.4.orig/siefs/Makefile.am	2004-08-13 08:45:30.000000000 +0200
+++ siefs-0.4/siefs/Makefile.am	2005-01-12 20:49:27.000000000 +0100
@@ -1,6 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
-CFLAGS = -I$(fuseinst)/include
+CFLAGS = -I$(fuseinst)/include -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=11
 
 bin_PROGRAMS = siefs slink
 

Re: [fuse-devel] Merging?

[Christian Axelsson]

Andrew Morton wrote:
> heh.  What userspace filesystems have thus-far been developed, and what are
> people using them for?

Im using the LUFS bridge from time to time for nice access to remote 
filesystems over ssh. I also plan to use the bluetooth filesystem (btfs) 
as soon as I get my #/%" bluetooth adapter working again ;)

For a list of other more or less serious filesystems (as gmailfs) 
checkout http://fuse.sourceforge.net/filesystems.html

-- 
Regards,
Christian

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> >  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?

Sshfs (idea shamelessly stolen from the LUFS project).  If you can ssh
to some host you can also mount it as a normal user like this:

   mkdir /tmp/kempelen
   sshfs mszeredi@kempelen: /tmp/kempelen

It pretty much trumps all other network filesystems wrt ease of server
setup, it's secure, efficient, all you need in a network filesystem :)

(available from http://sourceforge.net/projects/fuse; needs
fuse-2.2-pre3 and libglib-2.0)

Miklos

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> Perhaps a little heavyweight but it would solve an outstanding problem 
> which is "I have the software, I have the hardware, hell, why should I 
> type my root password to mount a ****ing iso ?" :)

Exactly!

In fact it's not so heavyweight either.  A standalone UML binary which
just contains all the major filesystems and the core kernel is little
over 3Mbytes.  It's smaller than many binaries even without their
library dependencies.  It loads in less than a second...  The linux
kernel is still pretty nice and lean!

Miklos

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> I like fuse, but I do not think Linus and Akpm have enough mails
> already. Getting it merged to some distribution might do the
> trick....

I know debian and gentoo already carry packages.  It doesn't get it
closer to inclusion though.

Miklos

Re: [fuse-devel] Merging?

[Diego Calleja]

El Wed, 12 Jan 2005 11:01:09 -0800 Andrew Morton <akpm@osdl.org> escribió:

> Miklos Szeredi <miklos@szeredi.hu> 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?

I know of several gmailfs users (mount your 1GB-space gmail account an use it
to get put things and retrieve them anywhere)

(If it gets into mainline people will probably stop developing things for
gnome-vfs/kioslave and use FUSE instead for "desktops")

Re: [fuse-devel] Merging?

[Pavel Machek]

Hi!

> > I like fuse, but I do not think Linus and Akpm have enough mails
> > already. Getting it merged to some distribution might do the
> > trick....
> 
> I know debian and gentoo already carry packages.  It doesn't get it
> closer to inclusion though.

Does Debian carry kernel patched with FUSE patches by default?

								Pavel
PS: IIRC and not speaking for suse: I think suse was seriously
thinking about using FUSE by default. It did not work well enough back
then. Not sure who exactly was working on it...
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [fuse-devel] Merging?

[Tomasz Torcz]

On Wed, Jan 12, 2005 at 09:51:57PM +0100, Diego Calleja wrote:
> (If it gets into mainline people will probably stop developing things for
> gnome-vfs/kioslave and use FUSE instead for "desktops")

  Not likely. GNOME/KDE are crossplatform. FUSE is Linux specific.

-- 
Tomasz Torcz                Only gods can safely risk perfection,
zdzichu@irc.-nie.spam-.pl     it's a dangerous thing for a man.  -- Alia

Re: [fuse-devel] Merging?

[Miklos Szeredi]

> Does Debian carry kernel patched with FUSE patches by default?

No.

> 								Pavel
> PS: IIRC and not speaking for suse: I think suse was seriously
> thinking about using FUSE by default. It did not work well enough back
> then. Not sure who exactly was working on it...

Well, they never talked with me about it.

Thanks,
Miklos

Re: [fuse-devel] Merging?

[Bernhard Schauer]

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

I'm a little bit confused... a few weeks ago I read a thread regarding
the remove of some - unneeded ? - symbols from IEEE1394 core. Some
persons in the discussion told, that everything should be included into
kernel mainline, cause if not, symbols needed may be removed. 

Now here is the discussion about including FUSE into kernel... So WHAT?
In any case, I do not think that FUSE, compiled in as module, could
bother someone. 

regards

Bernhard 

Re: [fuse-devel] Merging?

[Pavel Machek]

Hi!

> > -You could implement several "not-performance-critical" filesystems (fat,
> >  isofs) with FUSE to avoid possible security issues. Give that nowadays 
> >  usb sticks and cd/dvds are so common it'd be possible to modify a filesystem
> >  on purpose to crash the kernel if a bug were found in those filesytems. With
> >  FUSE that posibility decreases.
> 
> One of my pet ideas, is a userspace loopback mounter, which would use
> UML to actually mount an image, and export the resulting filesystem
> through FUSE to the host.
> 
> Brilliant isn't it?

Uh, yes, it actually makes sense.

OTOH perhaps porting linux's vfs to userland would be better idea.
People would like to tap on .iso images in mc to open them, but running
full UML to do this is little heavy-weight solution.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [fuse-devel] Merging?

[Pavel Machek]

Hi!

> >  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?

Right now, every project (mc, gnome, kde) has their own vfs implementation,
so that they can work transparently over ftp, handle archives, etc.

Done properly, userspace filesystem like fuse can unify those, plus provide better caching.
It also has chance to be a place for  niche filesystems (like atari800) that would be too much pain to keep in kernel.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [fuse-devel] Merging?

[Nix]

On 12 Jan 2005, Diego Calleja said:
> -Since you can use other programming languages, I suposse it'd be easier for
>  people to write support for weird filesystems.

Very weird, since the FUSE C library layer is small enough that if needs
be you can rewrite *that* in other languages as well.

I have plans for a Guile version of the userspace part of FUSE, for
instance, and some filesystems written in Guile: you certainly couldn't
do *that* in the kernel.

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery

Re: [fuse-devel] Merging?

[Steve McIntyre]

Andrew Morton wrote:
>Miklos Szeredi <miklos@szeredi.hu> 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?

At Plasmon we've developed a userland driver for our new UDO (Ultra
Density Optical) drive using FUSE. To avoid the complexity of
supporting a native 8KB sector size directly in kernel, we have
instead used FUSE to allow us to work on filesystems in
userland. That's made life _very_ much easier for us...

FUSE is very cool - there are many useful things that can be done with
it. Kudos to Miklos and others for their work on it!

-- 
Steve McIntyre, Plasmon                       smcintyre@software.plasmon.com
For more information on UDO, visit www.udo.com

Re: [fuse-devel] Merging?

[Luca Ferroni]

Il Wed, 12 Jan 2005 11:01:09 -0800,  Andrew Morton <akpm@osdl.org> ha scritto:

> Miklos Szeredi <miklos@szeredi.hu> 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?

For my master laurea thesis I developed PackageFS that aims to 
transparently manage packages in several distros.
There are also many other facilities:
- View a directory-based tree of packages (with the files that each package owns)
which can be nested by category, or by priority

In the future
- you will be able to add users to "packages" group to make them able 
to manage packages
- you can mount the file system on a cluster to transparently manage
several hosts

You can find my thesis at http://packagefs.sourceforge.net

I think FUSE is a very good idea (as good as the actual implementation is),
IMHO it should be inserted in the mainline kernel.
Thanks to Miklos and other developers. 

Luca
-- 
Non ci toglieranno mai....la LIBERTA'!!!
Luca Ferroni
ICQ #317977679
www.cs.unibo.it/~fferroni/

Re: [fuse-devel] Merging?

[Yaroslav Rastrigin]

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

Re: [fuse-devel] Merging?

[Vincenzo Ciancia]

Andrew Morton wrote:

> Miklos Szeredi <miklos@szeredi.hu> 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

Re: [fuse-devel] Merging?

[Hubert Tonneau]

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

Linux tree does not want zilion filesystems to be merged in, even if it's
supposed to be an open system, and the reason is that it would be a nightmare
to update all of them with each VFS, locking, etc changes.

So, FUSE is a must because it enables all these strange filesystems for special
purpose (Pliant http://pliant.cx/ can use it as an example to export part of
it's internal VFS, and nobody cares about Pliant),
to have minimal deal with Linux kernel internal details, and to not crash the
all machine in case of small problem in the strange filesystem.

The only serious objection to not using FUSE for strange filesystems is speed,
so here are some numbers:
On the test machine I found that using a native fisystem (EXT3) as the storage
backend, I can server files at 200 MB/second (using loopback as the network layer),
and using a user land over FUSE filesystem as the storage backend, I can serve
files at 50 MB/second.

If you read the second number, you discover that the speed penality is not
serious except for very demanding servers or applications, because the nowdays
disks throughoutput is also rougly 50 MB/second.
So in my test, if I had not done the test on a small 100 MB file already loaded
in the Linux cache, the effective speed would have been roughly the same.