Fuse for FreeBSD: announcement and more

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fuse for FreeBSD: announcement and more

Csaba Henk

I'm glad to announce Fuse for FreeBSD.

You can find information about this project (availability of code, source code
browsing, etc.) on (the wikipage serving as) its homepage,


There are two ways of making friends with it. One is, of course,
fetching, compiling, and using it. The drawback of this approach that
you need to be able to put your hands on a box running FreeBSD 6.x or

The other way is for those developer types who'd like to take a quick glance at
the means to a working Fuse under FreeBSD. They can read my
IMPLEMENTATION_NOTES. Apart from providing information about Fuse for FreeBSD,
there is a chance that you'll find this document insightful if you are not
familiar with at least one of the following: Linux VFS internals, FreeBSD VFS
internals, Linux Fuse internals. This doc was born with the intention of being
posted to this list, but finally it grew out to a standalone document and now I
just post here its availability:


and its TOC as a teaser:

1) Mounting
* 1a -- interface
* 1b -- security
* 1c -- dealing with the "allow other" misery
* 1d -- anything else
2) [vi]node operations
3) Syncing
4) Messaging
5) Miscellaneous

I'd take corrections happily if I've gone astray somewhere.

Now lets go for the future.

I seek integration with the parent projects.

There is a good chance that the kernel module will be integrated into
FreeBSD sooner or later, but of course, I also had to make some
userspace modifications. Not that much, thanks to the high portability
of the Fuse library: mainly header inclusions, some struct field
alterations, and some adjustments in the user interface related parts.

I'd like to ask for merging my library changes into the official Fuse
code. Some sanitization will be needed though... Eg, I didn't touch
autotools related files (in the installation instructions I just tell
how to hack around the way they work currently). Generating configure
files (for non-release snapshots) doesn't even work under FreeBSD.

Further ideas:

* I'd like to have... Well, I know, it's sort of naive to start a sentence
  this way. You could say this will fall into the same category as wishing
  to have a fast car or a big house, hence it's off topic. Nevertheless, I

  I'd like to have a comprehensive benchmark for Fuse.

  A Fuse-based tmpfs (ie. one which stores all file data in core) would
  be the first component for this. Is there such a beast? I didn't find
  one in Filesystems (but it might be done in few lines via some of the
  script language bindings, and that might be good for this purpose). It
  should be then extended with logging capabilities and some kind of
  runtime control interface (setting watchpoints...). It could feature a
  malicious mode to stress-test the kernel... And then a benchmarking
  program should be made, which does various characteristic I/O activities
  (similar to test/test.c), with support for various kind of time
  measurements. It could also have a malicious mode, in which it would
  perform file operations with the intention of deadlock the module or
  kill the daemon. A way to get staticits of the number of
  kernel/userspace messages would be desirable, too (although it could be
  done separately, right now, simply via analyzing daemons' debug

  So, I'm dreaming, and I know I won't do anything for this dream to
  come true. Yet if someone has some code snippets which realise some of
  the above, I'd appreciate hearing about it.

* I'd like to have... Yes, again, but this time I'm actually willing to
  do something for it. I'd like to have a world-writable wiki. This wish
  stems from the desire to collect user experience about various Fuse
  based filesystems under FreeBSD, but wikies tend to quickly grow beyond
  their original scope.

  I can put together such a wiki any day (khrm, so-so). But instead of
  making a private wiki and just dropping the url into this list and some
  others, wouldn't it be better to have an official Fuse wiki (which then,
  among others, could serve my needs as explained above)? A possible
  solution would be that I put together a private wiki and then Miklos
  takes the steps to anoint it as "official". Or Miklos, you could
  manage it by yourself, if you feel like so... though I guess you would
  have it done already if you felt like so.


SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
fuse-devel mailing list
[hidden email]