[tahoe-dev] Another FUSE interface

[zooko]

On Apr 27, 2008, at 12:55 PM, Armin Rigo wrote:

> For now, a link is probably more appropriate.

Okay:

http://allmydata.org/trac/tahoe/changeset/2516

>   At some point I plan to
> refactor this "hack/pyfuse/" directory into a clean library on the one
> hand, and actual file systems implemented with this library on the  
> other
> hand.  If this occurs, the cleanest solution might then be to let the
> tahoe file system live in Tahoe's contrib/ dir, alongside a copy of
> (some version of) this library.

Yes, that sounds good.

> write access (of course);

Nathan Wilcox's fuse interface (currently known as "contrib/ 
fuse_a" [1]) has basic write access.  Oh no, I asked Nathan on IRC  
and he said that, while he did write system tests to test write  
access, he may or may not have finished the actual write access.

> "http range" reads;

This would require the Tahoe backend to support HTTP range reads  
(ticket #288).

> a way to read the caps of files and directories and to add files and
> directores by giving their caps;

This is interesting -- the Tahoe back-end already supports it, but  
how would a POSIX-oriented application access this functionality?   
Some sort of "metadata" API?

> some correspondance between the Posix
> "write" permission and the read-only-ness of caps;

This one sounds easy -- just clear the write-permission bit on all  
read-only caps.

> and a local on-disk
> cache with a configurable size, which could also act as a write buffer
> to avoid blocking applications during write() and close().

It is unfortunate that this is needed -- it would be better if Tahoe  
did streaming writes in the first place (ticket #320) -- applications  
typically don't mind blocking long enough to do a normal network  
filesystem operation.

Note that ticket #320 would not be sufficient for other uses which  
are allowed by POSIX, such as seeking and overwriting.  We have plans  
for making more efficient implementations of such operations [2].

However, I think we should first satisfy the common need to just  
efficiently write out on sequential copy of a file.

By the way, are you aware of the *third* fuse interface?  Rob  
Kinninmont's mac fuse interface: [3].

> In fact I
> suspect that not all files written to the Fuse filesystem should
> automatically be uploaded (e.g. vim and emacs backup files...).  Maybe
> a "check-in" model would be appropriate.

That's interesting -- again I wonder what the API would be like.   
Perhaps for starters we should fix up the CLI.  Speaking of which, I  
will now investigate why Ben Laurie's attempt to use the CLI failed.

Regards,

Zooko

[1] http://allmydata.org/trac/tahoe/browser/contrib/fuse_a?rev=2516
[2] http://allmydata.org/trac/tahoe/browser/docs/mutable-DSA.txt
[3] http://allmydata.org/trac/tahoe/browser/mac/tahoefuse.py

tickets mentioned in this e-mail:

http://allmydata.org/trac/tahoe/ticket/288 # (resumption of  
interrupted downloads)
http://allmydata.org/trac/tahoe/ticket/320 # (add streaming upload to  
HTTP interface)
http://allmydata.org/trac/tahoe/ticket/393 # (mutable: implement MDMF)