In message <
20030103224112.GD4354@servalan>, Matthew Toseland
<[EMAIL PROTECTED]> writes
On Mon, Dec 30, 2002 at 08:36:04AM +0000, Roger Hayter wrote:
In message <20021230021553.GA4231@servalan>, Matthew Toseland
<[EMAIL PROTECTED]> writes
>On Sun, Dec 29, 2002 at 06:03:22PM -0800, [EMAIL PROTECTED] wrote:
>>I've proven that data store overrun causes insertion tools like FIW to
>>fail. The symptom is that the program stops midway through its
>>insertion sequence and sits idle.
>>
>>I figured this out from looking at my datastore usage. It should be
>>1Gig max, but when FIW failed it was at 1.3G. I increased the store
>>size to 2Gb, and now its running smoothly.
>>
>>I thought the datastore code was supposed to be intelligent and delete
>>the oldes material, making room for the new? Evidently, its not
>>working.
>It does work. There is a problem with tempfiles for fproxy or for the
>distservlet growing without limit. You will find that most of the extra
>space comes from the store/temp/ directory.
This is NOT what is happening to my node with recent 'unstable'
snapshots! Using one of the last two or three days' snapshots, my
store, limited to 256MB, grew to about 350MB. You tend to notice these
things using a 504MB disk! Deleting .../store_****/temp gained about
30MB and there was not even 10MB in the other places you mention. Many
of the individual data store folders were 1 to 3MB (obviously have to
average 1MB to keep under limit). Going back to one of the earlier
versions of build 629 (restarting the existing one didn't help), the log
file during start up shows dozens of:
Exactly what version are you seeing this behaviour with? Does it go away
with more recent builds (637) ?
I'm afraid I'm a bit careless about noting within-build build numbers,
and I haven't the room to compile the thing on the target machine. But
I am fairly sure it was the last snapshot version of 629. However, it
hasn't happened with later builds, and it took two days to happen when
it did (probably because my node is not handling a great quantity of
data!). I'll let you know if it recurs, unless you think it is
important enough to set up a node on another machine - but that would be
a different kernel version anyway.
"<date>(freenet.node.rt.DataObjectRoutingStore,main): Removing orphaned
property"
and the data store went back down to about 256MB plus a few temp files.
There is clearly something wrong in recent snapshots with the mechanism
for keeping data store size to the limit. It was (as others have noted)
only limited by partition size.
>>
>>Rob.
>
--
Roger Hayter
_______________________________________________
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
--
Roger Hayter
_______________________________________________
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
