Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The Datastore is the disk space used by Freenet to store data. All data on Freenet resides in the datastore of one or more nodes. For a mix of security and performance reasons, there are actually four different places data can be kept. The resulting names are rather confusing, and an improved set would be most welcome! These places are:
The cache provides a repository for most blocks passing through the node.
The store is similar to the cache, but fewer blocks get placed in it, meaning that blocks in the store last longer. This provides long-term storage for the network.
The client cache hold blocks requested directly by the user; for security, these blocks are not used to answer external requests.
The ULPR cache or short-term cache holds any block passing through the node without exceptions, but only for a short time. This helps protect against certain attacks.
The term datastore refers to the cache plus the store (occasionally the term is used sloppily to refer to just the store, but this is considered incorrect); this is the portion of the data that is most relevant to network behavior.
The store and cache work together to provide the main storage for the network. They are the same size. The cache is simple: a copy of every block that passes through the node is placed in the cache (with some exceptions, explained below). Unfortunately, for most nodes, this means that the cache rapidly fills up; when this happens, old blocks are dropped from the cache to make room for newer ones. If there was only the cache, files would not last long. To combat this, there is also a store. Only a fraction of blocks passing through the node get placed in the store: only blocks being inserted, not fetched, go into the store, and only if the node has a better location for the block than either adjacent node along the route. Because of this, the store takes a longer time to fill up, and blocks in the store last longer before being overwritten. In order to make more efficient use of the space available, as the cache becomes full, blocks in the cache may be placed in the store instead, but marked as cache blocks (as long as there is space in the store).
The client cache and ULPR cache together solve the problem of The Register's attack: if you download a file, and then the Bad Guys seize your computer, they can easily see that you downloaded the file because all the data is local. To combat this, blocks requested or inserted at high HTL are not placed in either the store or the cache.