INN commit: trunk/doc (FAQ pod/inn.conf.pod pod/install.pod)

INN Commit rra at isc.org
Tue Jan 5 20:29:16 UTC 2021


    Date: Tuesday, January 5, 2021 @ 12:29:16
  Author: iulius
Revision: 10499

Detail and homogenize the description of our 4 overview methods

Modified:
  trunk/doc/FAQ
  trunk/doc/pod/inn.conf.pod
  trunk/doc/pod/install.pod

------------------+
 FAQ              |   36 ++++++++++++++++++++++++++----------
 pod/inn.conf.pod |   30 ++++++++++++++++++++++++------
 pod/install.pod  |   41 ++++++++++++++++++++++++-----------------
 3 files changed, 74 insertions(+), 33 deletions(-)

Modified: FAQ
===================================================================
--- FAQ	2021-01-05 16:11:07 UTC (rev 10498)
+++ FAQ	2021-01-05 20:29:16 UTC (rev 10499)
@@ -454,17 +454,33 @@
 Any INN server that supports readers must therefore have an overview
 method configured.  There are four different methods to choose from:
 
-  - buffindexed, which is fast at writing because it uses preconfigured
-    large buffers like CNFS, but which is hard to recover;
-  - ovdb, which stores overview information in a Berkeley DB database
-    and supports compression;
-  - ovsqlite, implemented in INN 2.7.0, which stores overview information
-    in an SQLite database and supports compression, but still not as
-    widely tested as the other overview mechanisms (all introduced with
-    INN 2.3.0);
-  - tradindexed, which is the slowest but the best tested, the most
-    reliable and the method with the best recovery tools.
+  - buffindexed, which stores overview data and index information
+    into preconfigured large files like CNFS.  Fast at writing, the
+    buffindexed overview storage method can keep up with a large feed
+    more easily and never consumes additional disk space beyond that
+    allocated to these buffers.  The downside is that these buffers
+    are hard to recover in case of corruption and somewhat slower for
+    readers and the expiry process;
 
+  - ovdb, which stores overview information into a Berkeley DB database,
+    whose ddevelopment pace has stalled these last years.  This method
+    is fast and very robust, but may require more disk space, unless
+    compression is enabled.  Overview data is fetched one article at a
+    time, which makes this method a bit slower than ovsqlite for readers;
+
+  - ovsqlite, which stores overview information into an SQLite database,
+    known for its long-term stability and compatibility.  Robust and
+    faster than ovdb at reading ranges of overview data (since overview
+    data is transferred in 128-kilobyte chunks between ovsqlite-server
+    and nnrpd) but somewhat slower at writing, this method may require
+    more disk space, unless compression is enabled;
+
+  - tradindexed, which uses two files per newsgroup, one containing
+    the overview data and one containing the index.  Fast for readers,
+    but slow to write to because it has to update two files for each
+    incoming article.  Its main advantage is to be the best tested,
+    the most reliable and the method with the best recovery tools.
+
 ------------------------------
 
 Subject: 2.5. What are deferrals (NNTP code 431)?

Modified: pod/inn.conf.pod
===================================================================
--- pod/inn.conf.pod	2021-01-05 16:11:07 UTC (rev 10498)
+++ pod/inn.conf.pod	2021-01-05 20:29:16 UTC (rev 10499)
@@ -602,22 +602,40 @@
 
 =item C<buffindexed>
 
-Stores overview data and index information into buffers, which are
-preconfigured files defined in F<buffindexed.conf>.  C<buffindexed> never
+It stores overview data and index information into preconfigured
+large files like CNFS.  Fast at writing, the C<buffindexed> overview
+storage method can keep up with a large feed more easily and never
 consumes additional disk space beyond that allocated to these buffers.
+The downside is that these buffers are hard to recover in case of
+corruption and somewhat slower for readers and the expiry process.
+See the buffindexed.conf(5) man page for more details, and notably how
+to create the buffers.
 
 =item C<ovdb>
 
-Stores data into a S<Berkeley DB> database.  See the ovdb(5) man page.
+It stores overview information into a S<Berkeley DB> database, whose
+development pace has stalled these last years.  This method is fast
+and very robust, but may require more disk space, unless compression
+is enabled.  Overview data is fetched one article at a time, which makes
+this method a bit slower than C<ovsqlite> for readers.  See the ovdb(5)
+man page for more details.
 
 =item C<ovsqlite>
 
-Stores data into an SQLite database.  See the ovsqlite(5) man page.
+It stores overview information into an SQLite database, known for its
+long-term stability and compatibility.  Robust and faster than C<ovdb>
+at reading ranges of overview data (since overview data is transferred in
+128-kilobyte chunks between B<ovsqlite-server> and B<nnrpd>) but somewhat
+slower at writing, this method may require more disk space, unless
+compression is enabled.  See the ovsqlite(5) man page for more details.
 
 =item C<tradindexed>
 
-Uses two files per newsgroup, one containing the overview data and one
-containing the index.  Fast for readers, but slow to write to.
+It uses two files per newsgroup, one containing the overview data
+and one containing the index.  Fast for readers, but slow to write to
+because it has to update two files for each incoming article.  Its main
+advantage is to be the best tested, the most reliable and the method
+with the best recovery tools.
 
 =back
 

Modified: pod/install.pod
===================================================================
--- pod/install.pod	2021-01-05 16:11:07 UTC (rev 10498)
+++ pod/install.pod	2021-01-05 20:29:16 UTC (rev 10499)
@@ -687,37 +687,44 @@
 
 If your news server will be supporting readers, you'll also need to choose
 an overview storage mechanism (by setting I<ovmethod> in F<inn.conf>).
-There are three overview mechanisms to choose from:
+There are four overview mechanisms to choose from:
 
 =over 4
 
 =item buffindexed
 
-It can keep up with a large feed more easily, since it uses large buffers
-to store all overview information, but it's somewhat slower for readers
-(although not as slow as the unified overview in S<INN 2.2>).  You will need
-to create the buffers for it to use (very similar to creating CNFS buffers)
-and list the available buffers in F<buffindexed.conf>.  See
-buffindexed.conf(5) for more information.
+It stores overview data and index information into preconfigured large files
+like CNFS.  Fast at writing, the C<buffindexed> overview storage method
+can keep up with a large feed more easily and never consumes additional
+disk space beyond that allocated to these buffers.  The downside is that
+these buffers are hard to recover in case of corruption and somewhat
+slower for readers and the expiry process.  See the buffindexed.conf(5)
+man page for more details, and notably how to create the buffers.
 
 =item ovdb
 
-It stores overview data in a S<Berkeley DB> database; it is fast and very
-robust, but may require more disk space, unless compression is enabled.
-See the ovdb(5) man page for more information on it.
+It stores overview information into a S<Berkeley DB> database, whose
+development pace has stalled these last years.  This method is fast
+and very robust, but may require more disk space, unless compression
+is enabled.  Overview data is fetched one article at a time, which makes
+this method a bit slower than C<ovsqlite> for readers.  See the ovdb(5)
+man page for more details.
 
 =item ovsqlite
 
-It stores overview data in an SQLite database, known for its long-term
-stability and compatibility.  It is robust and faster at reading ranges
-of overview data, but somewhat slower at writing.  It may also require
-more disk space, unless compression is enabled.  See the ovsqlite(5)
-man page for more information on it.
+It stores overview information into an SQLite database, known for its
+long-term stability and compatibility.  Robust and faster than C<ovdb> 
+at reading ranges of overview data (since overview data is transferred in
+128-kilobyte chunks between B<ovsqlite-server> and B<nnrpd>) but somewhat
+slower at writing, this method may require more disk space, unless
+compression is enabled.  See the ovsqlite(5) man page for more details.
 
 =item tradindexed
 
-It is very fast for readers, but it has to update two files for each
-incoming article and can be quite slow to write.  Robust and well-tested,
+It uses two files per newsgroup, one containing the overview data 
+and one containing the index.  Fast for readers, but slow to write to 
+because it has to update two files for each incoming article.  Its main
+advantage is to be the best tested, the most reliable and the method
 with the best recovery tools.
 
 =back



More information about the inn-committers mailing list