mono-fuse

mono-fuse copied to clipboard

This is a Mono/.NET binding for FUSE.

Short HOWTO:

Within one terminal: sudo /sbin/modprobe fuse # need FUSE kernel module to use. ./configure make cd example/HelloFS mkdir t ./hellofs t

Within another terminal cd example/HelloFS ls t cat t/hello

This should display files controlled by HelloFS.exe.

To unmount the filesystem, you need to use the `fusermount' program: cd example/HelloFS fusermount -u t

KILLING THE FUSE PROGRAM IS NOT ENOUGH. The program will die, but FUSE and the kernel will still think that the directory is mounted. Result: you can't remount the directory, and trying to do anything with it will result in IO errors.

For full trace output, set the MONO_TRACE_LISTENER environment variable and add the -odebug command-line argument:

cd example/HelloFS
MONO_TRACE_LISTENER=Console.Out### ./hellofs -odebug t

MONO_TRACE_LISTENER controls the Mono.Fuse trace output, while -odebug controls the libfuse-generated trace output.

hellofs' also takes its own command-line aruments. By default, it exports two files, data' and hello'. hello' contains the string "Hello World!", while `data' is a 100 MB (base 10) file that generates its content on-demand.

If you pass the --data.im-in-memory flag, a data.im' file will be available which is a 100MB (base 10) file with the same contents as data', but it is backed by a 100MB byte[] instead of generating its contents on demand:

cd example/HelloFS
./hellofs --data.im-in-memory t

The 100MB byte[] is allocated the first time the contents of `data.im' are read.

`data.im' is useful to see the difference in performance between generate-on-demand and cached behaviors:

cd example/HelloFS
./hellofs --data.im-in-memory t

# On-demand copy
time cp t/data f.txt
	real    0m8.469s
	user    0m0.020s
	sys     0m1.128s

# In-memory copy
# Note that the first `data.im' access is longer
# because it needed to allocate the array.
# Subsequent calls are shorter:
time \cp -f t/data.im f.txt
	real    0m12.393s
	user    0m0.004s
	sys     0m1.172s
time \cp -f t/data.im f.txt
	real    0m5.233s
	user    0m0.016s
	sys     0m1.136s

# And for comparison, cp without FUSE:
time cp f.txt f2.txt
	real    0m10.252s
	user    0m0.016s
	sys     0m1.000s

And yes, on my machine it's faster to go through FUSE than to go through the filesystem (though usually the filesystem outperforms the on-demand generation). My machine is probably misconfigured. :-/ Your mileage will vary.