From 1c08ee91f68220c1904efbb278f6641403380474 Mon Sep 17 00:00:00 2001 From: Nikolaus Rath Date: Sun, 16 Oct 2016 15:05:57 -0700 Subject: Various documentation updates Move README.NFS into doc/ Update project URL Remove reference to non-existent INSTALL file Remove outdated/obsolete NEWS and how-fuse-works files. Update references to examples. --- doc/Makefile.am | 2 +- doc/README.NFS | 33 +++++++++++++++++++++++++++++++++ doc/how-fuse-works | 54 ------------------------------------------------------ doc/kernel.txt | 2 +- 4 files changed, 35 insertions(+), 56 deletions(-) create mode 100644 doc/README.NFS delete mode 100644 doc/how-fuse-works (limited to 'doc') diff --git a/doc/Makefile.am b/doc/Makefile.am index 2f2fa0f..1644383 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -2,4 +2,4 @@ dist_man_MANS = fusermount.1 mount.fuse.8 -EXTRA_DIST = how-fuse-works kernel.txt Doxyfile html +EXTRA_DIST = kernel.txt Doxyfile html README.NFS developer-notes.rst diff --git a/doc/README.NFS b/doc/README.NFS new file mode 100644 index 0000000..f3348d5 --- /dev/null +++ b/doc/README.NFS @@ -0,0 +1,33 @@ +NFS exporting is supported in Linux kernels 2.6.27 or later. + +You need to add an fsid=NNN option to /etc/exports to make exporting a +FUSE directory work. + +Filesystem support +------------------ + +NFS exporting works to some extent on all fuse filesystems, but not +perfectly. This is due to the stateless nature of the protocol, the +server has no way of knowing whether the client is keeping a reference +to a file or not, and hence that file may be removed from the server's +cache. In that case there has to be a way to look up that object +using the inode number, otherwise an ESTALE error will be returned. + +1) low-level interface + +Filesystems need to implement special lookups for the names "." and +"..". The former may be requested on any inode, including +non-directories, while the latter is only requested for directories. +Otherwise these special lookups should behave identically to ordinary +lookups. + +2) high-level interface + +Because the high-level interface is path based, it is not possible to +delegate looking up by inode to the filesystem. + +To work around this, currently a "noforget" option is provided, which +makes the library remember nodes forever. This will make the NFS +server happy, but also results in an ever growing memory footprint for +the filesystem. For this reason if the filesystem is large (or the +memory is small), then this option is not recommended. diff --git a/doc/how-fuse-works b/doc/how-fuse-works deleted file mode 100644 index a5febe3..0000000 --- a/doc/how-fuse-works +++ /dev/null @@ -1,54 +0,0 @@ - How Fuse-1.3 Works - -[Written by Terje Oseberg] - -1. The fuse library. - -When your user mode program calls fuse_main() (lib/helper.c), -fuse_main() parses the arguments passed to your user mode program, -then calls fuse_mount() (lib/mount.c). - -fuse_mount() creates a UNIX domain socket pair, then forks and execs -fusermount (util/fusermount.c) passing it one end of the socket in the -FUSE_COMMFD_ENV environment variable. - -fusermount (util/fusermount.c) makes sure that the fuse module is -loaded. fusermount then open /dev/fuse and send the file handle over a -UNIX domain socket back to fuse_mount(). - -fuse_mount() returns the filehandle for /dev/fuse to fuse_main(). - -fuse_main() calls fuse_new() (lib/fuse.c) which allocates the struct -fuse datastructure that stores and maintains a cached image of the -filesystem data. - -Lastly, fuse_main() calls either fuse_loop() (lib/fuse.c) or -fuse_loop_mt() (lib/fuse_mt.c) which both start to read the filesystem -system calls from the /dev/fuse, call the usermode functions -stored in struct fuse_operations datastructure before calling -fuse_main(). The results of those calls are then written back to the -/dev/fuse file where they can be forwarded back to the system -calls. - -2. The kernel module. - -The kernel module consists of two parts. First the proc filesystem -component in kernel/dev.c -and second the filesystem system calls -kernel/file.c, kernel/inode.c, and kernel/dir.c - -All the system calls in kernel/file.c, kernel/inode.c, and -kernel/dir.c make calls to either request_send(), -request_send_noreply(), or request_send_nonblock(). Most of the calls -(all but 2) are to request_send(). request_send() adds the request to, -"list of requests" structure (fc->pending), then waits for a response. -request_send_noreply() and request_send_nonblock() are both similar in -function to request_send() except that one is non-blocking, and the -other does not respond with a reply. - -The proc filesystem component in kernel/dev.c responds to file io -requests to the file /dev/fuse. fuse_dev_read() handles the -file reads and returns commands from the "list of requests" structure -to the calling program. fuse_dev_write() handles file writes and takes -the data written and places them into the req->out datastructure where -they can be returned to the system call through the "list of requests" -structure and request_send(). diff --git a/doc/kernel.txt b/doc/kernel.txt index 397a41a..fd3f174 100644 --- a/doc/kernel.txt +++ b/doc/kernel.txt @@ -49,7 +49,7 @@ using the sftp protocol. The userspace library and utilities are available from the FUSE homepage: - http://fuse.sourceforge.net/ + https://github.com/libfuse/libfuse/ Filesystem type ~~~~~~~~~~~~~~~ -- cgit v1.2.3