I want to use Tahoe-LAFS as the storage component of a network backup
application. In this application, each node hosts a backup application as well
as a full Tahoe node (storage server + client). The backup application can be
used to back up data on the node to the Tahoe storage network. I have found a
limitation of Tahoe-LAFS that makes it less than ideal for this type of
application.
Here’s the issue:
When you use Tahoe-LAFS with the introducer, every node is advertised as a
potential storage node. This includes the local node which is also is hosting a
Tahoe storage node. When the backup application is used to store local data to
the Tahoe-LAFS network, it may end up putting a slice of the data on its own
node. There are 2 problems with this:
It is wasteful of storage space
The local node already has a copy of the data so storing a slice locally does
not really improve resiliency.
It reduces resiliency
If the hard drive fails on the node, Tahoe slice stored on it may be lost.
I have discussed this issue with people on the tahoe-lafs IRC node and we came
up with a proposal for a new feature which addresses this issue.
The proposed new feature is to create a new configuration flag for the
Tahoe-LAFS client which prevents the client from storing data to its local
storage node (“don’t_use_local_storage”). When the flag is set, the client gets
the name of the local storage node from tahoe.cfg using the nickname attribute
of the [node] section. When the client creates a list of storage nodes to store
content to, it excludes this particular node from the list.
Make sense?
Bruce T
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
