[tahoe-dev] There's a a solution here --- somewhere.

[Ted Rolle, Jr.]

I apologize if this is an already-discussed issue...

Message from Tahoe-LAFS:

allmydata.interfaces.UploadUnhappinessError: shares could be placed on
only 4 server(s) such that any 3 of them have enough shares to recover
the file, but we were asked to place shares on at least 5 (shares.happy)
such servers. (placed all 7 (shares.total) shares, want to place shares
on at least 5 (shares.happy, again) servers such that any 3
(shares.needed) of them have enough shares to recover the file, sent 19
queries to 14 servers, 7 (shares.total?) queries placed some shares, 12
placed none (of which 2 placed none due to the server being full and 10
(2+10=12) placed none due to an error))\x0a"

10 not placed because of an error?  Can the message be specific?

And now the issue:

real   116m14.657s
user     0m0.660s
sys      0m0.120s

My Tahoe.cfg:
# What encoding parameters should this client use for uploads?
shares.needed = 3
shares.happy = 5
shares.total = 7

Almost 2 hours to both succeed and fail.  Can Tahoe-LAFS take over and
store shares on an "acceptable" number of servers, and do it quickly.

I seems that rigorous adherence to shares.happy is not the best way to
go.  If shares.happy can be a "suggestion," (+/- 1 or 2, specified, or
some algorithmically determined departure from the given value) would be
a better choice.
Like:
shares.happy = 5 (-1)
to specify that it's OK to store shares on 4 if it's taking too long,
like over a minute.  I'd prefer 5, but if that cannot be accomplished in
a timely manner, then 4 is good enough.

PITA-ingly,
Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120310/7d74b638/attachment.html>