[tahoe-dev] Why no error message when I have only one storage node?
Zooko Wilcox-O'Hearn
zooko at zooko.com
Mon Aug 10 08:48:01 PDT 2009
On Monday,2009-08-10, at 9:35 , Ludovic Courtès wrote:
> Zooko Wilcox-O'Hearn <zooko at zooko.com>
> writes:
>
>> On Monday,2009-08-10, at 9:18 , Ludovic Courtès wrote:
>>
>>> Having stored all shares on the user's node, will an eventual
>>> "tahoe deep-check --repair" reshuffle shares to other servers that
>>> have become available in the meantime?
>>
>> That would be ticket #699. It currently doesn't. Instead, the deep-
>> check detects that all of the shares are downloadable and quits,
>> happy that everything is right with the world.
>
> Thanks for the explanation.
>
> This issue is indeed critical for a backup use case.
I agree with your opinion that this is a serious issue and that it
would be really great if someone would fix it, but I'm not sure if I
would call it "critical", since people can and do use the current
version of Tahoe-LAFS for backup. I guess the way they work-around
this is some combination of (a) don't run a storage server on the
computer which has the data that they want to back up, and (b) make
sure that enough good storage servers are connected before doing a
backup.
Pretty kloogey! Note that there is a clump of tickets related to
#699. I think my personal favorite way to improve this would be for
someone to fix #573. I think it would solve your problem as well as
several other people's problems. I also would like to see #778
fixed. #573 and #778 both seem like easier changes to make than
#699. If someone like Kevan Carstensen wanted to get a little deeper
into Tahoe-LAFS code without getting in *too* deep, I would recommend
#573 or #778 but not #699. :-)
Regards,
Zooko
tickets mentioned in this email:
http://allmydata.org/trac/tahoe/ticket/699 # optionally rebalance
during repair or upload
http://allmydata.org/trac/tahoe/ticket/573 # Allow client to control
which storage servers receive shares
http://allmydata.org/trac/tahoe/ticket/778 # "shares of happiness" is
the wrong measure; "servers of happiness" is better
More information about the tahoe-dev
mailing list