linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Introducing FUSE: Filesystem in USErspace
@ 2001-11-12 11:28 Miklos Szeredi
  2001-11-17 17:52 ` Jamie Lokier
  2001-11-19  8:48 ` Miklos Szeredi
  0 siblings, 2 replies; 4+ messages in thread
From: Miklos Szeredi @ 2001-11-12 11:28 UTC (permalink / raw)
  To: linux-fsdevel, linux-kernel, avfs

Had enough of life?  Nothing to do?  Write a filesystem!

What is FUSE?

  FUSE (Filesystem in USErspace) provides a simple interface for
  userspace programs to export a virtual filesystem to the Linux
  kernel.  FUSE also aims to provide a secure method for non
  privileged users to create and mount their own filesystem
  implementations.

There's NFS or CODA. Why FUSE?

  Yes both NFS and CODA make it possible to create userspace
  filesystems.  But none of them were designed for this task.  The
  design of FUSE differs from the above in the following:

    - Ability to provide a _very_ simple userspace library interface.

    - Thin layer in kernel. Minimal caching, predictable behavior.

    - Communication is not over a network, and is optimized for local
      data transfer

    - Secure environment even if userspace client is non-cooperative.

All this is nice, but does it work?

  I've tested fuse with a simple 'loopback' test program, and also
  with AVFS (http://www.inf.bme.hu/~mszeredi/avfs/), for which FUSE
  was designed for.  That doesn't mean that there are no bugs in it,
  but it's a good sign...

Is it available?

  Yes it can be downloaded from

    http://sourceforge.net/projects/avf

How can it be installed?

  FUSE currently works only on 2.4.X kernels.  Installation requires
  the kernel source to be present.  The kernel does not need to be
  patched or recompiled: the kernel part of FUSE is installed as a
  module.  The FUSE module is SMP safe.

  There is also a kernel patch (for kernels 2.4.12 and up) included in
  the distribution, which makes mounting by non-privileged users
  secure.

Comments on design, implementation, and on my state of mind are
welcome.

Miklos

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Introducing FUSE: Filesystem in USErspace
  2001-11-12 11:28 Introducing FUSE: Filesystem in USErspace Miklos Szeredi
@ 2001-11-17 17:52 ` Jamie Lokier
  2001-11-18 16:35   ` Per-Olof Pettersson
  2001-11-19  8:48 ` Miklos Szeredi
  1 sibling, 1 reply; 4+ messages in thread
From: Jamie Lokier @ 2001-11-17 17:52 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: linux-fsdevel, linux-kernel, avfs

Miklos Szeredi wrote:
>     - Thin layer in kernel. Minimal caching, predictable behavior.

Minimal caching?  I would hope for maximal caching, for when userspace
is able to say "yes the page you have is still valid".  Preferably
without a round trip to userspace for every page.

-- Jamie

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Introducing FUSE: Filesystem in USErspace
  2001-11-17 17:52 ` Jamie Lokier
@ 2001-11-18 16:35   ` Per-Olof Pettersson
  0 siblings, 0 replies; 4+ messages in thread
From: Per-Olof Pettersson @ 2001-11-18 16:35 UTC (permalink / raw)
  To: Jamie Lokier, linux-kernel

Jamie Lokier wrote:

> Miklos Szeredi wrote:
> 
>>    - Thin layer in kernel. Minimal caching, predictable behavior.
>>
> 
> Minimal caching?  I would hope for maximal caching, for when userspace
> is able to say "yes the page you have is still valid".  Preferably
> without a round trip to userspace for every page.

Caching userspace filesystems is dependant of the implimentation. You 
would need to send some info to the kernel-part saying "Yes this part 
can be cached this long without a signal to userspace".

This would be equal to the caching-mechanism in a Web-server.

Most often the userspace-part would not know what parts will not change 
in a certain amount of time.. But then again.. Some implementations could.

Another way could be an explicit call to the kernel by the Userspace 
File System saying "Now this caching is no longer valid".

One implementation with static data could be a fs that is tied to a prog 
retrieving statistical data eg. Perhaps it is supposed to be run each 
hour. Then you would know "good enough" that the data has not been 
changed until next update. But suppose you manually restart the update 
of data, you would need to tell the kernel that caching of old data is 
not valid anymore.

Thing is you need the kernel-part to be told what can be cached, what 
cannot and how long it can be cached.

Then you would need a mechanism for the Userspace-part to make a caching 
invalid.

There is probably more into this than just these fundamentals.. And a 
simple working (not buggy) FS is preferred than a complicated (possibly 
buggy) FS that will never be released and is difficult to write 
userspace code for IMHO.

Best regards
Per-Olof Pettersson


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Introducing FUSE: Filesystem in USErspace
  2001-11-12 11:28 Introducing FUSE: Filesystem in USErspace Miklos Szeredi
  2001-11-17 17:52 ` Jamie Lokier
@ 2001-11-19  8:48 ` Miklos Szeredi
  1 sibling, 0 replies; 4+ messages in thread
From: Miklos Szeredi @ 2001-11-19  8:48 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-fsdevel, linux-kernel, avfs


> Minimal caching?  I would hope for maximal caching, for when userspace
> is able to say "yes the page you have is still valid".  Preferably
> without a round trip to userspace for every page.

I made some performance tests with FUSE, and the raw throughput is
about 60MBytes/s on a Celeron/360 for both reads and writes.  And yes,
that includes two context switches and a copy_to_user/copy_from_user
pair for each page.

I think that at such speed it's not really such a grave problem if
caching is not done in kernel, and it simplifies things a _lot_.

Miklos



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-11-19  8:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-12 11:28 Introducing FUSE: Filesystem in USErspace Miklos Szeredi
2001-11-17 17:52 ` Jamie Lokier
2001-11-18 16:35   ` Per-Olof Pettersson
2001-11-19  8:48 ` Miklos Szeredi

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