<div class="gmail_quote">On Fri, Sep 24, 2010 at 10:07 PM, Ravi Pinjala <span dir="ltr"><<a href="mailto:ravi@p-static.net">ravi@p-static.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Another (possibly even sillier) question: Is there a performance<br>
reason not to generate as many shares as possible, and only upload as<br>
many unique shares as we can to different hosts? This would be a<br>
completely different allocation strategy than what Tahoe uses now, but<br>
it might be more reliable. It'd also use as much space as possible,<br>
though, and the space usage wouldn't be very predictable, so actually<br>
upon reflection this isn't that great an idea. Still worth mentioning<br>
though, I think.<br></blockquote><div><br>The space usage could be controlled by also automatically varying K.  Rather than specifying K and M, you could define an expansion factor to use (e.g. 3.33).  Then M=N and K=M/3.33.  Happiness would probably be specified as a multiple of K (e.g. 2.1).  So for a grid with 10 active nodes, K=3, H=7 and M=10, but for a grid with 50 active nodes, K=15, H=32 and M=50.  There might be a better way to choose H.<br>
<br>However, none of this addresses the issue right now with the volunteer grid, which is that there are a small number of servers providing the bulk of the storage space.  Because that number is less than the default H (7), people using that value for H cannot upload to the volunteer grid because all of the smaller servers are full, in spite of the fact that there are nearly 20 active servers in the grid.<br>
<br></div></div>-- <br>Shawn<br>