From: nejucomo Date: Tue, 20 Nov 2007 20:58:42 +0000 (-0700) Subject: Add extensions/README and more doc strings to the fuse extension. X-Git-Tag: allmydata-tahoe-0.8.0~316 X-Git-Url: https://git.rkrishnan.org/zeppelin?a=commitdiff_plain;h=326aa73a6734de61e74fd71cfdf91955a50924ef;p=tahoe-lafs%2Ftahoe-lafs.git Add extensions/README and more doc strings to the fuse extension. --- 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. '''