linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [fuse-devel] Merging?
@ 2005-01-12 15:19 Hubert Tonneau
  0 siblings, 0 replies; 26+ messages in thread
From: Hubert Tonneau @ 2005-01-12 15:19 UTC (permalink / raw)
  To: linux-kernel

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


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [fuse-devel] Merging?
@ 2005-01-12 21:33 Vincenzo Ciancia
  2005-01-12 23:19 ` Yaroslav Rastrigin
  0 siblings, 1 reply; 26+ messages in thread
From: Vincenzo Ciancia @ 2005-01-12 21:33 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-01-18 22:24 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <loom.20041231T155940-548@post.gmane.org>
     [not found] ` <E1ClQi2-0004BO-00@dorka.pomaz.szeredi.hu>
2005-01-12 13:49   ` [fuse-devel] Merging? Miklos Szeredi
2005-01-12 14:31     ` Diego Calleja
2005-01-12 14:51       ` Miklos Szeredi
     [not found]         ` <200501122120.08217.vincenzo_mlRE.MOVE@yahoo.it>
2005-01-12 20:32           ` Miklos Szeredi
2005-01-13 14:08         ` Pavel Machek
2005-01-12 15:58       ` Florian Schanda
2005-01-12 16:16       ` Dobrica Pavlinusic
2005-01-14 11:37       ` Nix
2005-01-12 19:01     ` Andrew Morton
2005-01-12 19:15       ` Erik Hensema
2005-01-12 19:56         ` Miklos Szeredi
2005-01-12 20:15       ` Christian Axelsson
2005-01-12 20:19       ` Miklos Szeredi
2005-01-12 20:51       ` Diego Calleja
2005-01-12 21:15         ` Tomasz Torcz
2005-01-13 14:37       ` Pavel Machek
2005-01-17 17:01       ` Steve McIntyre
2005-01-18 22:23       ` Luca Ferroni
2005-01-12 19:44     ` Pavel Machek
2005-01-12 20:35       ` Miklos Szeredi
2005-01-12 20:56         ` Pavel Machek
2005-01-13  9:06           ` Miklos Szeredi
2005-01-13 10:52     ` Bernhard Schauer
2005-01-12 15:19 Hubert Tonneau
2005-01-12 21:33 Vincenzo Ciancia
2005-01-12 23:19 ` Yaroslav Rastrigin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).