On Sun, Aug 06, 2006 at 01:21:11PM +0300, Jusa Saari wrote: > On Sat, 05 Aug 2006 20:14:54 +0100, Matthew Toseland wrote: > > > Build 933 is now available from SVN and from emu (update.sh/cmd). Please > > test it. It will be released to the auto-updater on monday if no serious > > bugs are reported. This build fixes some datastore bugs, and includes > > recent work, converting the store to a short term cache and a long term > > store (the existing store becomes the cache). The long-term store only > > stores inserts, and only those for which the key is closer to this node > > than to any node on the insert chain so far. > > So, if the originating host happens to be the closest for the given key in > the entire network (which, in a network of a few hundred or at most few > thousand nodes and small file chunks is going to happen quite often), it > won't be stored at all, despite the insert seemingly completing > succesfully?
It will be stored on the cache in any case, but it won't be stored on the store of the first node. > > And of course, since nodes sometimes leave from the network or change > their position, even popular content's availability will deteriorate > steadily as it's permanently stored on less and less datastores. Not true. Popular content will be stored on the caches of most nodes. Semi-popular content won't be stored in so many caches, but will be stored in stores. And if locations change, this isn't a critical problem, as when content is successfully fetched, there is a chance of it being reinserted. Simulations show a significant improvement in success rate for a given amount of content, relative to caching everything in the cache and having no store (which is what we had). > > > 80% of the storeSize should eventually be used by the store rather than > > the cache, but to avoid major loss of content I have arranged for the > > cache to be gradually shrunk as the store grows. For a full store, this > > means that initially it will be cut by 20% and renamed to cache. If the > > node is then not restarted for a long time, it may use up to 60% over the > > storeSize limit. However, every time the node is restarted, the cache will > > be shrunk to make room for any growth in the store (up to the limits > > specified above; 20% of storeSize is always reserved for the cache), and > > if the cache is over the size limit it will not grow further. Given the > > frequency of updates, and given that the store grows slowly, hopefully > > this will not be a practical problem. This code will be removed before > > 0.7.0, but not for some time. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/support/attachments/20060807/983afca8/attachment.pgp>
