From 326aa73a6734de61e74fd71cfdf91955a50924ef Mon Sep 17 00:00:00 2001 From: nejucomo Date: Tue, 20 Nov 2007 13:58:42 -0700 Subject: [PATCH] Add extensions/README and more doc strings to the fuse extension. --- contrib/README | 3 --- contrib/tahoe-fuse.py | 30 ++++++++++++++++++++++++++++-- 2 files changed, 28 insertions(+), 5 deletions(-) delete mode 100644 contrib/README diff --git a/contrib/README b/contrib/README deleted file mode 100644 index ad776ba7..00000000 --- a/contrib/README +++ /dev/null @@ -1,3 +0,0 @@ -This directory contains code and extensions which are not strictly a part -of Tahoe. They may or may not currently work. - diff --git a/contrib/tahoe-fuse.py b/contrib/tahoe-fuse.py index 5981c4dc..ed61ac01 100644 --- a/contrib/tahoe-fuse.py +++ b/contrib/tahoe-fuse.py @@ -2,10 +2,36 @@ ''' Tahoe thin-client fuse module. + +Usage Notes: + +This is a proof-of-concept, and not production quality. It uses the +FUSE interface, and where bugs or unimplemented features are encountered +the file system may become confused. + +In my experience with ubuntu's linux version 2.6.20-16-generic, and +python-fuse version 2.5-5build1, the worst behavior is that processes +which are accessing the fuse filesystem when some bugs occur hang. +Also, the filesystem is currently single-threaded and blocking, so one +bug interrupts all filesystem client processes. + +The rest of my system seems stable even in these cases (the rest of the +filesystem and other processes function). + +The current design caches EACH FILE ENTIRELY IN MEMORY as long as any +process has that file open. Expect horrible memory usage. (But also, subsequent reads after the first should be fast. ;-) + + Goals: + - Delegate to Tahoe webapi as much as possible. -- Thin as possible. -- This is a proof-of-concept, not a usable product. +- Thin rather than clever. (Even when that means clunky.) + + +Status Quo: + +- Reads cache entire file contents, violating the thinness goal. Can we GET spans of files? +- Single threaded. ''' -- 2.45.2