n-1 peer selection: node should have a flag to never send shares to ourselves #96

Closed
opened 2007-08-09 20:05:15 +00:00 by warner · 1 comment
warner commented 2007-08-09 20:05:15 +00:00
Owner

robk astutely pointed out that, when tahoe is used as a backup application, you almost never want to store a share on the same node that provided the original file. Some of our use cases hit this one, some don't.

So I think we should have a configuration knob somewhere that influences the peer selection routine, by simply removing 'self' from the eligible list of storage servers. For small meshes in which people are running personal nodes (as opposed to a one-node-for-everyone webfront -kind of service), they can turn on this flag to only push shares to other nodes, never using themselves.

robk astutely pointed out that, when tahoe is used as a backup application, you almost never want to store a share on the same node that provided the original file. Some of our use cases hit this one, some don't. So I think we should have a configuration knob somewhere that influences the peer selection routine, by simply removing 'self' from the eligible list of storage servers. For small meshes in which people are running personal nodes (as opposed to a one-node-for-everyone webfront -kind of service), they can turn on this flag to only push shares to other nodes, never using themselves.
tahoe-lafs added the
code
major
enhancement
0.4.0
labels 2007-08-09 20:05:15 +00:00
tahoe-lafs added this to the undecided milestone 2007-08-09 20:05:15 +00:00
warner commented 2007-08-10 01:54:04 +00:00
Author
Owner

I went ahead and did this, because it turns out to have a significant effect on the node's memory footprint. For some reason, pushing shares back to ourselves increases our memory usage considerably. I have two theories: either foolscap is not freeing inbound method arguments as quickly as we'd like (maybe they're stuck in a reference cycle of some sort), or maybe the loopback broker has some similar misbehavior.

In any case, I've made the node not send shares to itself by default. To change this, write to a file named "push_to_ourselves" in the node's directory. The contents don't matter. If this file exists at startup, then the node will include itself in the list of peers considered as shareholders. If not, it will remove itself from the list.

I went ahead and did this, because it turns out to have a significant effect on the node's memory footprint. For some reason, pushing shares back to ourselves increases our memory usage considerably. I have two theories: either foolscap is not freeing inbound method arguments as quickly as we'd like (maybe they're stuck in a reference cycle of some sort), or maybe the loopback broker has some similar misbehavior. In any case, I've made the node *not* send shares to itself by default. To change this, write to a file named "push_to_ourselves" in the node's directory. The contents don't matter. If this file exists at startup, then the node will include itself in the list of peers considered as shareholders. If not, it will remove itself from the list.
tahoe-lafs added the
fixed
label 2007-08-10 01:54:04 +00:00
tahoe-lafs modified the milestone from undecided to 0.5.0 2007-08-10 01:54:04 +00:00
warner closed this issue 2007-08-10 01:54:04 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#96
No description provided.