On Dec 7, 2007, at 5:24 PM, Ed Tomlinson wrote: > On December 7, 2007, Robert Hailey wrote: >> [...] >> Consider the following patch (completed to the furthest point that my >> current freenet understand can take it). >> - If a CHKBlock is evicted from the datastore (not cache), AND we are >> not (as best we can tell) "close" to where it should be, THEN re- >> insert that block. >> >> This approximates the decision (is this eviction OLD/UNPOPULAR or >> UNFINDABLE), and brings with it a rather odd perk for having small >> datastores (that they would find these misplaced blocks sooner). >> >> The major risk, of course, is renewing old data. >> [...] > > This is an interesting way to tackle the problem. Might I suggest > that instead of > doing this for data that we are about to discard we do it select a > key from the DS > at random and reinsert if its far from our current location.
That may be a good strategy for shrinking the datastore, to slowly reinsert it into the network. But the problem is one of finding the initiative, such a task would yield itself to occurring when we change locations, which (if that is the case; that we have a store full of stuff for a different location) means we probably shouldn't be swapping locations to begin with (your first point). > One thing that may be happening that somewant offsets this problem > could be > clustering of locations. e.g. even though my nodes location changes > often it could > be that it favours some subsets of the total location space. It > would be worthing > adding a metric to track how long a node spends in a given area of > the location > space. Hmm... that may be implementable as a running average of (location over time). i.e. every fixed interval (hour? / 5-minute) average one 'location' into the running average. Which amounts to a location- shifting 'velocity' measurement, or 'average-location'. -- Robert Hailey
