Where should rrd files generated by a program be stored ?
Hi,
I have a discussion with my usptream (amavis-stats) where rrd files
should be stored. (This mail is an adaptation of a mail send by the
upstram.)
In the FHS, there is :
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or calculation. The
application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss. The data
must remain valid between invocations of the application and rebooting
the system.
Files located under /var/cache may be expired in an application specific
manner, by the system administrator, or both. The application must always
be able to recover from manual deletion of these files (generally because
of a disk space shortage). No other requirements are made on the data
format of the cache directories.
The rrd files are not stored on disk to save time or calculations. They
are the output of the program. There is no other reason for someone to
install amavis-stats other than to view the graphs generated from the
rrds.
Since the amavis log files are rotated, and eventually removed there is no
way to re-create the data.
/var/lib however has the following purpose:
This hierarchy holds state information pertaining to an application or
the system. State information is data that programs modify while they run,
and that pertains to one specific host. Users must never need to modify
files in /var/lib to configure a package's operation.
State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between
invocations and between different instances of the same application.
State information should generally remain valid after a reboot, should
not be logging output, and should not be spooled data.
Therefore rrd files should be stored in /var/lib, isn't it ?
However when looking to cacti, or mailgraph, they store rrd files in
/var/lib.
Any suggestion ?
Thanks.
--
Jean-Michel Kelbert
Reply to: