.. | ||
api.go | ||
bridge.go | ||
constants_darwin.go | ||
constants_linux.go | ||
constants.go | ||
default.go | ||
dirstream_darwin.go | ||
dirstream_linux.go | ||
dirstream.go | ||
files_darwin.go | ||
files_linux.go | ||
files.go | ||
inode.go | ||
loopback_darwin.go | ||
loopback_linux.go | ||
loopback.go | ||
mem.go | ||
mount.go | ||
README.md | ||
syscall_linux.go |
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.