Unexplainable disk space usage in nagios/var/spool/checkresults

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/01/10 08:22 AM, Casey Allen Shobe wrote:
> On Jan 27, 2010, at 1:40 AM, Thomas Guyot-Sionnest wrote:
>> I would highly recommend using tmpfs for the checkresults directory.
>> This is especially important on logging file systems like JFS, XFS,
>> Ext3+ and ReiserFS since every meta-data operation will cause a log
>> write+flush (at the very least) which will cause a constant stream of
>> unneeded IO.
> 
> 
> Thanks for the advice - this sounds perfectly practical, as long as
> those files are not important to persist across nagios restarts.  The
> JFS partition is on top of DRBD, so if I move to tmpfs, the contents
> will disappear when a failover happens - that should be okay I take it?

Absolutely. checkresults, temp files and status.dat don't need to stick
around. In normal circumstances there should not be any file left behind
in these directories after a clean shutdown.

This will also save you some useless network traffic if you can avoid
DRDB replication :)

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLYNMs6dZ+Kt5BchYRAiTfAJ4hLynuqHNndi8pFPm7GHKDrkao1gCgtm5o
ov6rKYEZf6KBufZmkhcBYz0=
=kbdH
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null