> > being stored in the Datastore, without any real safeguards in place to > > keep the routing table from being freed in favor of ordinary data. > > But .. that's impossible, since the routing table isn't stored under > a key, and only keys can be freed to reclaim space. Nevertheless, thats what was happening, the ranges indicated in the store file were occcupied by data blocks.
> > > I'm not entirely certain a complete redesign was necessary. In the original > > DFS code, the routing table and datastore index were stored in a separate > > file for a *reason*. > > Whether they are actually in separate files is pretty inconsequential in > my new design .. I'm basically just cutting off a region at the beginning > and using it like a separate file. As long as you GUARANTEE it can't be accessed for regular storage. > Fred already consumes large amounts of memory, and even with moderately > sized stores we can reduce that memory usage with a system like the one > I described. So? When people are devoting gigabytes to the store, their now running a server, not a background app. I agree memory reduction is a goal, however. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011112/5f98fb21/attachment.pgp>
