On Sunday 17 May 2009 22:24:57 Juiceman wrote: > 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?
True, it might be worth it. > > > 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. If we encrypt the persistent client layer, and only start it up with a password, then we will still want the rest of the node to work when we don't have the password. So probably we should have two databases...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
