File: README.md

package info (click to toggle)
golang-github-hanwen-go-fuse 2.1.0%2Bgit20220822.58a7e14-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 1,292 kB
  • sloc: cpp: 78; sh: 43; makefile: 16
file content (60 lines) | stat: -rw-r--r-- 2,188 bytes parent folder | download | duplicates (4)
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

Objective
=========

A high-performance FUSE API that minimizes pitfalls with writing
correct filesystems.

Decisions
=========

   * Nodes contain references to their children. This is useful
     because most filesystems will need to construct tree-like
     structures.

   * Nodes contain references to their parents. As a result, we can
     derive the path for each Inode, and there is no need for a
     separate PathFS.

   * Nodes can be "persistent", meaning their lifetime is not under
     control of the kernel. This is useful for constructing FS trees
     in advance, rather than driven by LOOKUP.

   * The NodeID for FS tree node must be defined on creation and are
     immutable. By contrast, reusing NodeIds (eg. rsc/bazil FUSE, as
     well as old go-fuse/fuse/nodefs) needs extra synchronization to
     avoid races with notify and FORGET, and makes handling the inode
     Generation more complicated.
     
   * The mode of an Inode is defined on creation.  Files cannot change
     type during their lifetime. This also prevents the common error
     of forgetting to return the filetype in Lookup/GetAttr.
     
   * The NodeID (used for communicating with kernel) is equal to
     Attr.Ino (value shown in Stat and Lstat return values.). 

   * No global treelock, to ensure scalability.

   * Support for hard links. libfuse doesn't support this in the
     high-level API.  Extra care for race conditions is needed when
     looking up the same file through different paths.

   * do not issue Notify{Entry,Delete} as part of
     AddChild/RmChild/MvChild: because NodeIDs are unique and
     immutable, there is no confusion about which nodes are
     invalidated, and the notification doesn't have to happen under
     lock.

   * Directory reading uses the DirStream. Semantics for rewinding
     directory reads, and adding files after opening (but before
     reading) are handled automatically. No support for directory
     seeks.

   * Method names are based on syscall names. Where there is no
     syscall (eg. "open directory"), we bias towards writing
     everything together (Opendir)

To do/To decide
=========

   * Symlink []byte vs string.