[tahoe-dev] detecting weak uploads and share rebalancing Re: Share rebalancing

[Zooko O'Whielacronx]

On Sat, Oct 10, 2009 at 7:41 PM, Shawn Willden <shawn at willden.org> wrote:
>
> It wouldn't change my FEC parameters?  I thought his patch would change the
> current parameters to mean servers instead of shares, so I would think that
> setting H and N larger than the number of servers in the grid would be a
> problem.  I have K = number_of_servers.

The idea has evolved quite a bit through the life of ticket #778 (and
its offspring #791).  The current idea uses the same K and N values to
mean how many shares to generate, but reinterprets H to mean not "I'll
be happy if at least H shares have been uploaded" but "I'll be happy
if at least H servers are holding distinct shares".

> I haven't followed the patch very closely.  I guess I should go read about it.
> A lot of the terminology in the description assumes knowledge of the code,
> though, so my perception is that it would take significant effort to
> understand.

Well, maybe you could contribute by judging whether the docs make
sense to you.  We shouldn't commit the patch if understanding how to
use it requires knowledge of the code (or at least, if it requires
*more* knowledge of the code than the current behavior requires).

http://allmydata.org/trac/tahoe/attachment/ticket/778/docs.txt

> I could do that, but I'd really like to get the shares to the *right* servers,
> per the permuted list, to minimize the likelihood that the repairer ends up
> placing shares poorly if the file has to be repaired.

Ah yes, this is an example of why I wish for #302.  If Tahoe-LAFS just
used the standard Chord ring that all modern distributed data systems
use, then you could figure out which shares go to which servers by
visually inspecting the storage indexes and the server ids.

Regards,

Zooko

http://allmydata.org/trac/tahoe/ticket/302 # stop permuting peerlist,
use SI as offset into ring instead?