My startup time has gone from a minute to around 20-30 minutes now. Same box, same size DS. I'm looking at what the DS is doing and, well... the phrase "Ugh" comes to mind. WHY are we re-inventing a wheel? Especially one that does not (at least to me) appear to be "round"?
There's lots of ways to fix this, but the easiest is to scrap the DS entirely and just use files-in-directories, and let the OS deal with it. If encryption is needed, just encrypt the key, store as base64 in a hierarchal directory structure. To see if something is present in the DS, attempt to access it. The LRU manager can be a seperate (encrypted) file and a thread that unlinks as we get close to the space threshold. Benifits: Startup time is instant for FS, nearly instant for LRU manager. It has to read in a state file, or if it's missing/corrupted has to scan the DS in the background. Can startup and start serving requests even if the LRU manager is rebuilding it's database. Knowledge from multiple other projects (squid, inn's timecaf) on how to manage. Most work is offloaded unto well tested* OS libraries/kernels. Looking up a key is close to instant. Drawbacks: Inode usage. Exposes key sizes (if not their contents). Huge Honkin Directories. Not Invented Here. Marking something 'recently accessed' is still limited by the JVM managing a 10 to 30k-node search structure. I volunteer. What encapsulates the needs of freenet (APIwise) best? FSDirectory.java? The LRU management? Or is that not-interesting to higher layers except for diagnostics? --Dan *excepting Windows. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
