Thank you Shawn, your example clarified things for me. I had a dim intuition that you might say something like what you did; specific numbers help me. Thanks much.
> Reliability and cost are independent and largely opposing parameters, so I > don't really know how you can evaluate that. Really? I find their opposition "natural" and hence not independent. All other things equal, the more reliable version costs more. There are obviously areas between the curves drawn by various erasure coding schemes, including extreme examples like k = 1 and k = M, and you can win at both cost and reliability in the margins. As you show, the "margin" can actually be significant. But as you note, > * Ignoring failures avoided by simplicity. we win the margin by changing the form of our payment: we save dollars, gain reliability, but pay in usability and development/debugging time. For example, if a user finds they mis-tuned the erasure coding paramters and needs to re-tune them later, they may actually have a net loss in dollars or even in reliability. In my experience at least ;) human error is much more likely than hardware error, and person (developer, sysadmin, user) time is much more expensive than hardware. Additionally, although I now see why you say k = 1 is the least reliable at a given cost, I suspect there is a cut-off point at which cost and reliability are good enough, and yet we save a margin of person (developer, sysadmin, user) time and error costs. Especially in an open source project, it's the latter savings I want to maximize. -- http://noncombatant.org/ _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
