On Sat, Oct 10, 2009 at 7:41 PM, Shawn Willden <[email protected]> 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? _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
