1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
This is a C# 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.
|
