#96 closed enhancement (fixed)

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

Reported by: warner Owned by: somebody
Priority: major Milestone: 0.5.0
Component: code Version: 0.4.0
Keywords: peer-selection Cc:
Launchpad Bug:

Description

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.

Change History (1)

comment:1 Changed at 2007-08-10T01:54:04Z by warner

  • Milestone changed from undecided to 0.5.0
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.