FUSE allows to write file systems
which are processes running in userspace.
A fuse process is launched with a mountpoint
as argument: it is the root path where the FS
will be available. Let's say its /mountpoint here
When launched, the process will fork
fusermount program via libfuse
fusermount is owned by root with setuid bit
The first thing fusermount does is ensure FUSE
driver is in the kernel: lets say its not
FUSE driver is inserted
FUSE filesystem is declared in the VFS
A misc block device is registered
a file appears in /sys to notify there's a new
block device
/proc/misc now contains the minor number for this device.
The major's is misc's (10)
Since a new block device appeared in /sys, udev creates
/dev/fuse (mknod based on misc's major and fuse minor)
/dev/fuse is available. fusermount can now:
Open /dev/fuse and send its fd to the
file system process for it
to comunicate with FUSE driver
mount -t fuse /dev/fuse /mountpoint
After this mount, VFS associates /mountpoint with
FUSE filesystem.
The filesystem in user space can now be used.
Let's say we launch an ls command on a file managed by
FUSE.
This will issue a stat syscall to the VFS.
Which will in turn call the stat implementation
from fuse.
This implementation will call request_send(),
which will add the request to the list
of request structure.
the FS in userspace process, via libfuse,
reads /dev/fuse.
The FUSE in kernel driver callback fuse_dev_read()
is called.
The callback returns commands from the list
of request to libfuse
libfuse calls the the FS in userspace
implementation of stat
The FS returns its result
Then libfuse writes the result to /dev/fuse
This calls fuse_dev_write() which receives
the responses and places them in req->out
request_send() unblocks as there is a response.
it sends its result to the stat implementation
ls process receives the stats generated
by fuse process.
