Feature request and proposal for Tahoe-LAFS

brucet brucet.cisco at gmail.com
Mon Sep 16 18:31:10 UTC 2019


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20190916/1bd86cbb/attachment.html>


More information about the tahoe-dev mailing list