notes.txt

Project
- Document not just how to use our library, but provide a much needed guide on
  how each fuse API call should be implemented.
- Provide a "TraceFS" implementation?


Go stuff

- Avoid the syscall package. It's deprecated.
- Prefer the os package over golang.org/x/sys/... where possible to avoid cross
  platform implementation pain.
- It may be easier to use C naming conventions for internal code?
- A good implementation will need a very good byte buffer pool.
- Use go style errors, not syscall numbers. Keep it idiomatic.


Fuse specific notes
- On linux, the fuse fd can be cloned for reduced contention
- We should open /dev/fuse directly if possible, falling back to fusermount
- Every request has {id, uid, gid, pid, nodeid, opcode}. Do we want to make this
  generally available/exposed?
- Can locks be handled opaquely, or must they be exposed?
- Stat structs vary across OS implementations. Commonality?
- Every fuse request contains fuse_in_header, including the init request. What
  is the maximum length of a fuse request? What's the smallest buffer size we
  can get away with?


architecture notes

1 Server: 1 Session: N Workers: N Requests

Lifetimes
    Server - serve to shutdown
    Session - mount to unmount, each time new generation id
    Worker - bounded by init to destroy, dynamic spinup
    Request - serialized request -> response, unless async?


Links
- http://man7.org/linux/man-pages/man4/fuse.4.html
- http://ptspts.blogspot.com/2009/11/fuse-protocol-tutorial-for-linux-26.html
- https://www.kernel.org/doc/Documentation/filesystems/fuse.txt
- https://github.com/libfuse/libfuse