Evan and Matthew,

Like I said, I don't have the time to monitor the node that closely. When it's down, I clear the logs if they have gotten out of control, restart the node, and pray that nothing corrupted.

I have turned the log level down to "error" and limited the logs to 8MB to try and control them. But even then I've seen the current log file explode to over 1.5GBytes. Of course the node crashed when disk space ran out.

I've setup the node on special drive partitions. I set it up with 3GBytes extra. That was not enough as I discovered weeks later. I expanded the partition by 3GBytes more, but that was the limit. To go higher I need to move the large partitions around between multiple hard drives. That takes too much time. Maybe some day.

It would be nice if the node would not let the current log file get out of control. Put the limits on all log files, including the wrapper logs (those get quite large too). Then fail out gracefully when disk space runs out. Then when the node restarts, put up a message and interface that lets the user stop a few downloads to free up some space before the node fully starts up. Without this, the node will just fail out again before it gets fully up.


On Apr 14, 2010, at 10:25 AM, Evan Daniel wrote:

On Wed, Apr 14, 2010 at 1:16 PM, Matthew Toseland
<t...@amphibian.dyndns.org> wrote:
On Saturday 10 April 2010 21:53:24 freenet wrote:

I don't monitor the node that closely. The reason for the crashes
varies. It seems to usually be a "null pointer exception".

Usually this isn't fatal. It would be interesting to see the logs. I assume this is shown in wrapper.log?

Other times
it just crashes out with no warning. Other times it runs out of disk
space. When that happens the entire Freenet installation virtually
self destructs, corrupting key files, mostly the persistent temp files
and the .db4o database. I have to totally wipe those to recover the
node. The datastore seems to survive all crashes ok. Freenet really
should handle running out of disk space better than this.

Until Java 1.6 we don't even know how much disk space is available. And most embedded databases (thankfully not the one we use) corrupt themselves unrecoverably on out of disk space. Just pointing out that it's not as easy a problem as you might think. Really the solution is for the user to set a sensible space limit, rather than filling up the entire partition with datastore and then using even more for downloads. And we do try to help the user there, by suggesting a fraction of the detected disk size in the installer.

So I've turned the log level down to minimum to help prevent runaway
disk usage. Hence I no longer see much info on what might have made
the node crash. I did manage to increase the size of the partition
that Freenet runs from by about 2GBytes and decrease the size of the
datastore by 1GByte. So far no more running out of disk space.

Ah, so it's THE LOG FILES that fill up the disk? Freenet rotates log files once an hour, and there is a limit on the total size of the log files, defaulting to 128MB - but unfortunately this only includes the compressed rotated log files, not the "live" log files. In any case if we are using 500MB+ for one hour's logs something is seriously wrong - I suggest in that case you shut down the node, if necessary delete everything else, and send me as much of the compressed logfile as you can.

Well, there's another issue as well: Freenet uses more space for the
datastore than configured, by about 2-3%.

Evan Daniel

Support mailing list
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to