mirror of
https://github.com/tahoe-lafs/tahoe-lafs.git
synced 2024-12-27 08:22:32 +00:00
236c52bf8b
from my examination of the tahoe_fuse ('impl_a') code, it looks like
the intention is to cache the file contents in memory while it's open,
since it does in fact do that. however it looks like it also ignored
that cache entirely, and made an individual tahoe webapi GET request
for each and every read() operation regardless of the relative size of
the read block and the file in question.
this changes that to make read() use the data in memory rather than
fetch the data over again. if there's something more subtle going
on, please let me know.
|
||
|---|---|---|
| .. | ||
| README | ||
| tahoe_fuse.py | ||
Welcome to the tahoe fuse interface prototype! Dependencies: In addition to a working tahoe installation, this interface depends on the python-fuse interface. This package is available on Ubuntu systems as "python-fuse". It is only known to work with ubuntu package version "2.5-5build1". The latest ubuntu package (version "1:0.2-pre3-3") appears to not work currently. Unfortunately this package appears poorly maintained (notice the wildy different version strings and changing API semantics), so if you know of a good replacement pythonic fuse interface, please let tahoe-dev know about it! Configuration: Currently tahoe-fuse.py uses the same ~/.tahoe/private/root_dir.cap file (which is also the CLI default). This is not configurable yet. Place a directory cap in this file. (Hint: If you can run "tahoe ls" and see a directory listing, this file is properly configured.) Commandline: The usage is "tahoe-fuse.py <mountpoint>". The mount point needs to be an existing directory which should be empty. (If it's not empty the contents will be safe, but unavailable while the tahoe-fuse.py process is mounted there.) Usage: To use the interface, use other programs to poke around the mountpoint. You should be able to see the same contents as you would by using the CLI or WUI for the same directory cap. Runtime Behavior Notes: Read-only: Only reading a tahoe grid is supported, which is reflected in the permission modes. With Tahoe 0.7.0, write access should be easier to implement, but is not yet present. In-Memory File Caching: Currently requesting a particular file for read causes the entire file to be retrieved into tahoe-fuse.py memory before the read operation returns! This caching is reused for subsequent reads. Beware large files. When transitioning to a finer-grained fuse api, this caching should be replaced with straight-forward calls to the wapi. In my opinion, the Tahoe node should do all the caching tricks, so that extensions such as tahoe-fuse.py can be simple and thin. Backgrounding Behavior: When using the 2.5-5build1 ubuntu package, and no other arguments besides a mountpoint to tahoe-fuse.py, the process should remain in the foreground and print debug information. Other python-fuse versions appear to alter this behavior and may fork the process to the background and obscure the log output. Bonus points to whomever discovers the fate of these poor log messages in this case. "Investigative Logging": This prototype is designed to aide in further fuse development, so currently *every* fuse interface call figures out the process from which the file system request originates, then it figures out that processes commandline (this uses the /proc file system). This is handy for interactive inspection of what kinds of behavior invokes which file system operations, but may not work for you. To disable this inspection, edit the source and comment out all of the "@debugcall" [FIXME: double check python ref name] method decorators by inserting a '#' so it looks like "#@debugcall" (without quotes). Not-to-spec: The current version was not implemented according to any spec and makes quite a few dubious "guesses" for what data to pass the fuse interface. You may see bizarre values, which may potentialy confuse any processes visiting the files under the mount point. Serial, blocking operations: Most fuse operations result in one or more http calls to the WAPI. These are serial and blocking (at least for the tested python-fuse version 2.5-5build1), so access to this file system is quite inefficient. Good luck!