Feature request and proposal for Tahoe-LAFS

brucet brucet.cisco at gmail.com
Tue Sep 24 18:46:29 UTC 2019


Jean-Paul,

 

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

 

Great!! I am working on something else right now but will get to this soon.

 

PS. I am having an issue with the magic-folder feature that I will post to this mail alias later this week.

 

Thanks again,

 

                Bruce T

From: Jean-Paul Calderone <jean-paul+tahoe-dev at leastauthority.com>
Date: Tuesday, September 24, 2019 at 10:23 AM
To: Bruce Thompson <brucet.cisco at gmail.com>
Cc: <tahoe-dev at tahoe-lafs.org>, Pierre Malhaire <pierre.malhaire at gmail.com>, eduardo gonzalez <eduardogonzalez at ged-innovations.com>, Brian Thompson <brianbthompson at sbcglobal.net>
Subject: Re: Feature request and proposal for Tahoe-LAFS

 

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:
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?

 

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/1c21f93a/attachment.html>


More information about the tahoe-dev mailing list