On 6/14/07, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
It's actually not that simple. Please do read [0] and [1]. Roughly, whether erasure coding improves data *availability* over simple replication (which is what we care about in a backup system) depends on a number of factors, notably individual peer availability. That is, if you pick up untrusted backup buddies at random on the Internet, it may be the case that you'd be better off using simple replication than erasure coding for a given storage overhead (from an availability viewpoint).
You are right regarding availability and coding, but in flŭd, where nodes are free to choose trading partners based on locally observed reliability, this is taken into account. Backup can be fundamentally different than filesharing in that nodes /should be/ much less transient. Filesharing's common use case is 1) connect to network, 2) download file[s], 3) disconnect. Backup's common use case, on the other hand, is to continuously monitor the filesystem for changes and backup these modifications ASAP. Nodes who are actively participating in a backup network have a self-interest in remaining connected (or reachable) /continuously/. In flŭd, there is an extra incentive for remaining available; a node which does not remain available consistently will have a very hard time finding partners willing to trade storage and bandwidth resources. Currently, this means that if you want to do backup but don't want to leave your computer connected all the time, you'd be better off using something like mozy or, as David suggested, paying for an S3 solution* (I do have some ideas for how to allow unreliable nodes to use flŭd, but fleshing them out is not high priority at the moment). Alen *of course, since flŭd is still uber-experimental at this stage, you'd want to have a /real/ backup plan anyway
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
