<div class="gmail_quote">On Sun, Nov 7, 2010 at 10:20 AM, Jimmy Tang <span dir="ltr"><<a href="mailto:jcftang@gmail.com">jcftang@gmail.com</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;">
<div dir="ltr"><div class="im"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote"></div>
</div>How many storage nodes would your system have?<br></blockquote></div><br></div><div>I'm going to start with 3 servers at first, I have about 40 old machines that i can re-provision for doing this if I really need to.</div>
</div></blockquote><div><br>Even with 40 machines, you shouldn't run into any issues with scalability from a performance perspective.  The commercial allmydata site had far more than that.<br><br>One thing you'll want to think carefully about is your choice of encoding parameters M and K.  What you want to make sure won't happen is for M-K servers to be down simultaneously, because if you have enough files, the loss of any M-K servers will make some of those files unavailable.  If you have deep directory trees, it becomes very likely that any given file is unavailable, because losing any directory node between root and leaf makes the leaf unavailable.<br>
<br>With only three servers, if the data is important I'd go with K=1, M=3.  That means that each server will store all of the data for all of the files.  K=2 would allow you to lose only one server, a second problem would result in the loss of all data.<br>
<br>With 40 servers, I'd set M close to 40.  Maybe 35.  Then I'd set K to about 25.  That means you'd have to lose 10 servers before any healthy files were lost.  Losing 16 servers would lose all of your data, but it's vanishingly unlikely that any independent sort of failure mode would take out that many before you could run a repair, and any failure that affects that many would probably affect all of them anyway.<br>
<br>If you're paranoid you could go with K=20 or even K=15, but I don't think your reliability would be any higher in practice.<br><br>Note that Tahoe has not been tested much with larger values of K and M.  Nearly all usage has been with the default values of K=3, M=10.  I wouldn't expect that using larger values would uncover data-loss bugs, but it might uncover some performance issues.   Probably not, but you'd need to test to be sure.<br>
<br>One thing you wouldn't need to worry about much, IMO, is performance degrading as more files are added.  Performance is dependent on bandwidth, number of servers and encoding parameters, it's not really sensitive to data volumes or file counts.<br>
</div></div><br>-- <br>Shawn<br>