On Fri, May 15, 2009 at 2:37 PM, Matthew Toseland <t...@amphibian.dyndns.org> wrote: > On Wednesday 13 May 2009 18:29:47 Evan Daniel wrote: >> On Wed, May 13, 2009 at 7:33 AM, Matthew Toseland >> <t...@amphibian.dyndns.org> wrote: >> > On Friday 08 May 2009 17:40:58 Juiceman wrote: >> >> >> Weird. node.db4o was an insane 375 MB. I deleted it and and added a >> >> >> bunch of downloads. Now it is less than 10 MB. That definitely >> >> >> helped some with the disk thrashing. >> >> >> >> >> >> I think I found the main problem, and I'm embarrassed to say >> >> >> apparantly I had xmlspider plugin running and writing GB+ files to the >> >> >> same disk the node resides on. I turned this off and the disk usage >> >> >> became manageable. >> >> >> >> >> >> I also upgraded my HDD from an older 2 MB cache model to one with 16 >> >> >> MB and now Freenet is zipping along nicely. >> >> >> >> >> >> I did see some errors in the log so I am sending it to Toad for > review. >> >> >> >> >> >> P.S. I would recommend not installing the xmlspider by default on >> > installs. >> >> >> >> >> >> Victor - might this be your issue as well? >> >> > >> >> > ROFL. So that just leaves victor... >> >> >> >> Is it normal that node.db4o never shrinks? I have completed all the >> >> downloads I had running and removed them from the page, yet node.db4o >> >> doesn't get smaller. I have rebooted the node also. This IMHO is bad >> >> because it will eventually kill performance with disk access... >> > >> > Yes, the only way to ensure it shrinks is to defrag it. This is on the > todo >> > list, but it does not seem urgent to me. Is it really a huge, monstrous, >> > evil, all-consuming problem more urgent than the 500 other things we have > to >> > deal with? >> >> I see two issues. First, my node.db4o has broken 100MiB. That's not >> a problem, but eventually it would be. I can deal with this by >> emptying my download / upload queues, deleting it, and re-adding any >> keys, but that's annoying. It's not urgent, but an option to defrag >> at startup would be nice if it doesn't take too much of your time. >> >> Second issue is a minor security thing. I'm probably less paranoid >> than most Freenet users, but I would like to know that after I >> download a file, the traces left behind by doing so are well defined. >> That would include the file itself and the fact that its blocks are in >> my cache. I'd rather not also have that info in the node.db4o file >> (is it encrypted?). Again, not urgent, but worth dealing with >> eventually. The truly paranoid will have motion detectors that >> unmount their encrypted filesystems and start scrubbing RAM before the >> Bad Guys (TM) can sit down at the keyboard, right? >> >> Evan Daniel > > On Thursday 14 May 2009 01:54:02 Dennis Nezic wrote: >> >> Or have the node automatically delete it when the queues are empty? > > Automatically deleting node.db4o when there is nothing queued might work. The > main problem is that we would then not be able to put things other than > queued requests into it. Meaning if we want to persist e.g. stats, passive > requests etc, we will need a separate database.
Is that much work? Have a filequeue.db4o and a nodeinfo.db4o Then we can safely delete the filequeue when there are no pending persistent requests? > We don't encrypt node.db4o at present. We should have the option of encrypting > it for those who don't want to encrypt the whole drive, but then we would > need a way to ask the user for the password on startup, or put it in some > easily shreddable file (shredding files doesn't work with modern > filesystems). > > But for the really paranoid, db4o is a bit of a PITA. There is no way we can > guarantee that no traces of old requests are present, because db4o doesn't > have garbage collection. All we can say is we've tested it and debugged the > leaks found by the tests. But it is certainly possible for bugs introduced > since then, or not found, to cause leakage of objects. _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
