The first thing to decide is how INN should store articles on your system. There are four different methods for you to choose from, all of which have their own advantages and disadvantages. INN can support all four at the same time, so you can store certain newsgroups in one method and other newsgroups in another method.
The supported storage formats are:
This is the storage method used by all versions of INN previous to 2.0. Articles are stored as individual text files whose names are the same as the article number. The articles are divided up into directories based on the newsgroup name. For example, article 12345 in news.software.nntp would be stored as news/software/nntp/12345 relative to the root of the article spool.
Advantages: Widely used and well-understood storage mechanism, can read article spools written by older versions of INN, compatible with all third-party INN add-ons, provides easy and direct access to the articles stored on your server and makes writing programs that fiddle with the news spool very easy, and gives you fine control over article retention times.
Disadvantages: Takes a very fast file system and I/O system to keep up with current Usenet traffic volues due to file system overhead. Groups with heavy traffic tend to create a bottleneck because of inefficiencies in storing large numbers of article files in a single directory. Requires a nightly expire program to delete old articles out of the news spool, a process that can slow down the server for several hours or more.
Articles are stored as individual files as in tradspool, but are divided into directories based on the arrival time to ensure that no single directory contains so many files as to cause a bottleneck.
Advantages: Heavy traffic groups do not cause bottlenecks, and fine control of article retention time is still possible.
Disadvantages: The ability to easily find all articles in a given newsgroup and manually fiddle with the article spool is lost, and INN still suffers from speed degredation due to file system overhead (creating and deleting individual files is a slow operation).
Similar to timehash, articles are stored by arrival time, but instead of writing a separate file for each article, multiple articles are put in the same file.
Advantages: Roughly four times faster than timehash for article writes, since much of the file system overhead is bypassed, while still retaining the same fine control over article retention time.
Disadvantages: Even worse than timehash, and similar to cnfs (below), using this method means giving up all but the most careful manually fiddling with your article spool. As one of the newer and least widely used storage types, timecaf has not been as thoroughly tested as the other methods.
CNFS stores articles sequentially in pre-configured buffer files. When the end of the buffer is reached articles new articles are stored from the beginning of the buffer, overwriting older articles.
Advantages: Blazingly fast because no file creations or deletions are necessary to store an article. Unlike all other storage methods, does not require manual article expiration; old articles are deleted to make room for new ones when the buffers get too full. Also, with CNFS your server will never throttle itself due to a full spool disk, and groups are restricted to just the buffer files you give them so that they can never use more than the amount of disk space you allocate to them.
Disadvantages: Article retention times are more difficult to control because old articles are overwritten automatically. Attacks on Usenet, such as flooding or massive amounts of spam, can cause wanted articles to expire much faster than you intended with no warning.
Some general recommendations: If you are installing a transit news server (one that just accepts news and sends it out again to other servers and doesn't support any readers), use CNFS exclusively and don't worry about any of the other storage methods. Otherwise, put high-volume groups and groups whose articles you don't need to keep around very long (binaries groups, *.jobs*, news.lists.filters, etc.) in CNFS buffers, and use timehash, timecaf, or tradspool (if you have a fast I/O subsystem or need to be able to go through the spool manually) for everything else. You'll probably find it most convenient to keep special hierarchies like local hierarchies and hierarchies that should never expire in tradspool.