[tahoe-dev] RelatedProjects
Nathan
nejucomo at gmail.com
Wed Feb 11 09:20:16 PST 2009
On Tue, Feb 10, 2009 at 3:16 PM, zooko <zooko at zooko.com> wrote:
> On Feb 10, 2009, at 16:11 PM, Andrej Falout wrote:
>
>>> blackmatch -- Rob Kinninmont's FUSE implementation
>>
>> Might be worth noting that on my machine blackmatch stopped working
>> somewhere between r3465 and r3558 (FUSE error; cannot mount)
>
> Yes -- should be noted! Someone should open a ticket reporting this
> fact.
>
I'd be interested to know how the fuse tests fare in exposing this
problem. AFAIK, no one has used them recently, and they haven't been
run against blackmatch.
Here, I just added a ticket to address this:
http://allmydata.org/trac/tahoe/ticket/621
[snip...]
>>> contrib/fuse -- three different FUSE implementations by three
>>> different authors
>>
>> Of which one is above mentioned blackmatch.
>
> Whoops -- then what are all those things in the "mac/" subdirectory
> with "fuse" in their name? Is blackmatch copied into two locations
> in the current source tree?
>
I would like to see a single fuse implementation become "blessed"
as official. Why? So that most users test the same one, and so that
it receives automated test scrutiny.
Does anyone else like this idea?
Here is my impression of the differences between implementations:
fuse_a: Strives to be "thin". Uses a python fuse binding of dubious
quality. At one point had automated tests.
fuse_b: Uses a freshly written python wrapper using ctypes against
libfuse. (Correct?) At one point had (the same) automated tests.
blackmatch: Strives to be "smart" (versus thin) with caching, request
batching, etc... in order to optimize user experience. No automated
tests. (Correct?)
None of them are actively maintained. (Corrections?)
Nathan
More information about the tahoe-dev
mailing list