Some thoughts/info on stuff that should be done some day

1 files changed, 53 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..dbf4488
--- /dev/null
+++ b/README
@@ -0,0 +1,53 @@
+So far this is just a copy of the nullfs example from
+/usr/share/doc/python-fuse with some stuff renamed
+
+To make it work:
+
+- How do you get another arg in the options?
+    - pydoc fuse shows some magic option parser stuff
+    - need this for the "source" directory, or backing storage area
+- Better to compress chunks?  Or have a blob more like a zip?
+
+-----
+
+TODO:
+
++ Make inflate/deflate block based as needed, so we don't have to do a
+  bunch of work up front and waste a bunch of space on disk
+    - done
+- Make files just contain a backing storage key, this key will reference
+  what we have in it now (the data list and stat info) so that complete
+  duplicate files will not take up a few extra megs and still be able to
+  have their own permissions and stuff
++ Copying read-only files doens't work (permission denied on close, because
+  that is the point we are opening and writing to the original file)
+    - done - we open a file handle at __init__ now and use that
+- R/W is basically ignored at this point
+- fsck:
+    - test each chunk < last is a full block size (this would be a good
+      assert too)
+- delete unused chunks (refcounting)
+- pack multiple chunks in to "super chunks" like cromfs to get better
+  compression (e.g. 4M of data will compress better than that same file
+  split in to 4 1M pieces and compressed individually presumably)
+
+-----
+
+Other thoughts:
+
+- If there was an easy way to "open a file" or something and have it
+  "touch" all it's pieces, you could just run that in the mounted tree
+  then "find storage/ -mtime +1" and delete that stuff to clean out cruft
+- Alternatively have it keep track of block usage counts and when it goes
+  to "zero" then delete it
+    - Change load/save to be ref counted?  Or have another method for
+      "release" and "lock" to say "Yeah I'm using this" or "This is garbage
+        now?"
+- Possibly better compression to be had if you use a squashfs sort of block
+  of blocks.  So you get redundancy of small blocks (32k or whatever) and
+  pack those together in to big blocks (say 2-4M) then compress the big
+  block.  That way you get better compression in the big block.  The
+  question is if this constant inflating an deflating of blocks will be too
+  much of a performance hit
+      - Maybe have a "working set" of pre-expanded sub blocks?  And
+        automatically freeze out blocks when all the files are closed?