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.
Paul
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:
Matthew,
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%.
https://bugs.freenetproject.org/view.php?id=3689
Evan Daniel
_______________________________________________
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
