[flud-devel] [p2p-hackers] announcing Allmydata-Tahoe v0.3
alenlpeacock at gmail.com
Thu Jun 14 17:49:53 PDT 2007
On 6/14/07, Ludovic Courtès <ludovic.courtes at laas.fr> wrote:
> It's actually not that simple. Please do read  and . 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).
*of course, since flŭd is still uber-experimental at this stage, you'd
want to have a /real/ backup plan anyway
More information about the flud-devel