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