go-tfhfs

NOTE: This project is now officially stalled, as in practical
benchmarking it is simply not fast enough. The modern SSDs
(gigabytes/second, crazy IOPS) and fuse (few hundred megabytes/second,
slower IOPS) are simply not match made in heaven it seems.

This is the next-generation rewrite (Dec 2017 - Mar 2018) of my earlier
tfhfs project that was written in
Python. This can be considered pre-alpha; it mostly works, but I do not
recommend using it yet except to test if you are curious.

Design changes:

• using inodes instead of paths as bases for the btree forest => semantics
  more closely match UNIX

• implement it in Go, instead of Python (mostly because FUSE performance at
  least on OS X seems rather horrid within Python compared to Go; see my
  fuse bindings benchmark
  for more details

• make the design leverage parallelism much more ( parallel sha256,
  encryption, tree merging )

Performance figures

Build

# go get github.com/fingon/go-tfhfs/...

(or get it via git for the amusing sanitytest.sh)

Usage

With go get, the tools of interest are tfhfs and tfhfs-connector
binaries (more documentation TBD, look at sanitytest.sh or usage if you
feel adventurous).

With git checkout, after running make, the main point of entry is
./sanitytest.sh which runs minimal test which consists of:

• mounting one volume at /tmp/x (with server at localhost:12345)

• mounting second volume at /tmp/y (with server at localhost:12346)

• copying thigs from root filesystem (/bin/ls mainly) and setting things up
  in /tmp/x

• synchronizing the state between /tmp/x and /tmp/y using tfhfs-connector
  utility

• umounting /tmp/x, /tmp/y

• remounting /tmp/x using the same fixed storage

• still ensuring /tmp/x has state we set up there

NOTE: You REALLY do not want to expose tfhfs server to non-localhost use
at the moment; it is plain HTTP/1.1 without any security
mechanisms. However, as the block content itself is not plaintext, and it
performs relatively rigorous checks on input, even exposing it to public
Internet will have only not particularly bad outcomes:

• resource exhaustion attack (store lot of blocks)

• network utilization attack (get blocks ad nauseaum)

• (limited) synchronization mischief; can attempt to merge in bit older
  roots, but typically merge routine should simply ignore this.

Used tests to verify sanity

• My FUSE oriented variant of fstest: https://github.com/fingon/fstest (fuse
  branch)

• fstorture from Apple fstools: https://github.com/macosforge/fstools

Known limitations

See TODO