diff options
| -rw-r--r-- | README | 53 |
1 files changed, 53 insertions, 0 deletions
@@ -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? |