Attached a patch for the rrd-tool LIBDBI integration with the following improvements:

[rrdtool.git] / doc / rrdtool.pod

diff --git a/doc/rrdtool.pod b/doc/rrdtool.pod
index cd3c785..84749af 100644 (file)
--- a/doc/rrdtool.pod
+++ b/doc/rrdtool.pod
@@ -34,8 +34,8 @@ While the man pages talk of command line switches you have to set in
 order to make B<RRDtool> work it is important to note that
 B<RRDtool> can be remotely controlled through a set of pipes. This
 saves a considerable amount of startup time when you plan to make
-B<RRDtool> do a lot of things quickly. Check the section on L<"Remote
-Control"> further down. There is also a number of language bindings
+B<RRDtool> do a lot of things quickly. Check the section on L<Remote_Control>
+further down. There is also a number of language bindings
 for RRDtool which allow you to use it directly from perl, python, tcl,
 php, etc.
 
@@ -91,7 +91,11 @@ Change the size of individual RRAs. This is dangerous! Check L<rrdresize>.
 
 =item B<xport>
 
-Export data retrieved from one or several RRDs. Check L<rrdxport>
+Export data retrieved from one or several RRDs. Check L<rrdxport>.
+
+=item B<flush>
+
+Flush the values for a spcific RRD file from memory. Check L<rrdflush>.
 
 =item B<rrdcgi>
 
@@ -298,9 +302,17 @@ sockets, tools like netcat, or in a quick interactive test by using
 B<NOTE:> that there is no authentication with this feature! Do not setup
 such a port unless you are sure what you are doing.
 
+=head1 RRDCACHED, THE CACHING DAEMON
+
+For very big setups, updating thousands of RRD files often becomes a serious IO
+problem. If you run into such problems, you might want to take a look at
+L<rrdcached>, a caching daemon for RRDTool which may help you lessen the
+stress on your disks.
+
 =head1 SEE ALSO
 
-rrdcreate, rrdupdate, rrdgraph, rrddump, rrdfetch, rrdtune, rrdlast, rrdxport
+rrdcreate, rrdupdate, rrdgraph, rrddump, rrdfetch, rrdtune, rrdlast, rrdxport,
+rrdflush, rrdcached
 
 =head1 BUGS