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

New Issue

warner · 2007-08-09T20:05:15Z

warner commented

2007-08-09 20:05:15 +00:00

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.

warner added the

labels 2007-08-09 20:05:15 +00:00

warner added this to the undecided milestone 2007-08-09 20:05:15 +00:00

warner commented

2007-08-10 01:54:04 +00:00

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.