[tahoe-dev] FUSE and Tahoe

[Nathan]

Yay!  More fuse dev!


On Thu, Oct 2, 2008 at 2:04 PM, rob kinninmont <robk-tahoe at allmydata.com> wrote:
>
> I know there are numerous people who've expressed interested in FUSE
> support for tahoe, and perhaps moreover it seems many of those people
> were unaware of the third implementation, supporting write operations
> which lurked in the 'mac' subdirectory of the source tree.

This is good to hear.  I wrote the fuse_a as a kind of proof of
concept, but cannot dedicate my time to a full development effort.

I'd love, instead, to collapse the various implementations into a
single "official" fuse interface.  By collapse, I don't mean merging
code, rather, I mean focusing development effort.


[BTW- I snip chunks I don't directly respond to...]

About the pyfuse.sourceforge.net bindings:

The fuse C library implements its own event management system which
can either be single threaded or multithreaded (configurable by the
application or, ludicrously, by the user through commandline options).

See the description of "fuse_main()":
http://fuse.sourceforge.net/doxygen/fuse_8h.html#3bf31250361d44c2436d76f47f2400ed

I don't have a clear picture of how multiple threads calling into python works.


> Indeed chatting with some folks more
> knowledgeable than I turned up an example [3] using pyfuse and twisted
> to implement an sshfs.

It looks like the key building block for the threading model is
"callFromThread" decorator in exarkun's code.  (Confusingly, it has a
different interface than the reactor callFromThread, which is not a
decorator.)

I would expect with this design, multiple FS requests arrive into the
fuse library which dispatches them on multiple threads.  Those threads
then call into python, which uses the callFromThread-wrapped handler
functions to send the request to the reactor thread and block waiting
for the response.


> However I haven't been able to get these bindings to work on the Mac
> as yet.  They work fine (c.f. 'impl_b') on linux, but alas something
> seems to be awry in their interaction with macfuse.

Do you mean you have gotten neither python-fuse nor arigo's pyfuse
bindings working on osx?

If python-fuse works (fuse_a has automated tests), but fuse_b breaks,
it may indicate the ctypes approach is brittle across platforms.

If both fail, I expect it's an issue with the threading model.  Does
exarkun's sshfs run on osx?  If so, then we've found the culprit.  If
not...  ?


> I'm currently toying with a somewhat obnoxious construction of
> introducing yet another layer of indirection, another process
> boundary, whereby a fuse_main based threaded 'shim' process brokers
> requests to another twisted based process which implements the caching
> and logic layer, impedance matching fine grained fuse operations to
> coarse grained tahoe webapi requests.  This approach is odious enough
> that it is without doubt intended only as a stopgap workaround until
> some cross-platform twisted compatible fuse bindings can be nailed down.

When I wrote fuse_a I eschewed any complexity other than brain-dead
forwarding over the wapi of requests.  The trade-off was simplicity
instead of user experience.

My grand plan was to push all the hard work of caching onto the tahoe devs. ;-)

This appeals to me because the same caching and performance-usability
issues will pop up in any file-system like interface, so why not solve
it closest to where the decisions can be made wisely?

OTOH, it's probably faster to implement optimizations in the fuse
layer, which will keep core tahoe simpler, and provide a "proving
ground" for different strategies.


[snip..]

The road map:

> 1. Bindings to support twisted on the mac.  I'm afraid I'm currently a
> bit stumped by the pyfuse/mac, and python-fuse/threads/twisted issues,
> so I'm working on the aforementioned rather ugly workaround and
> focussing on the other enhancements below.  If anyone has any good
> ideas to offer on these issues, I'm all ears.

I propose testing exarkun's design out-of-the-box on osx.  If it
works, then there's a clear direction to integrating into a twisted
model.  If not, then there needs to me more debug sleuthing.

> 2. Cache management.  [snip...]
> 3. Concurrency, or non-blocking open.  [snip ...]
> 4. Streaming upload.  [snip...]

See above about where to put optimizations.  I'm now a fan of
developing them in fuse as both a faster path to performant usability
(because the feature wishlist remains more parallelizable and less
entangled), and as a proving ground.

In fact, now I'm a fan of putting off usability optimizations unless
they are present in two or more tahoe interfaces (be that WUI, fuse,
backup tool, etc...) and have the same solution.

>
> At any rate, if you have any questions about fuse support for tahoe,
> feel free to drop me a line.

Are there automated tests?  Has there been much linux QA?

Maybe I could adapt the test framework (which was itself klunky) for
fuse_a to support fuse_c ?  (The caveat being my limited and fractured
hobby time, so if you want a schedule, we'll have to negotiate.  ;-)

>
> cheers,
> rob
>
>


Nathan