Feature request and proposal for Tahoe-LAFS

Jean-Paul Calderone jean-paul+tahoe-dev at leastauthority.com
Tue Sep 24 16:23:30 UTC 2019


On Mon, Sep 16, 2019 at 2:31 PM brucet <brucet.cisco at gmail.com> wrote:

> 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:
>
>    1. 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.
>
>    1. 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?
>
>
Heya Bruce,

I think we discussed this on IRC.  Reading through your summary, it still
seems like it makes sense to me.

Jean-Paul


>
>
>                 Bruce T
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20190924/c4278966/attachment.html>


More information about the tahoe-dev mailing list