My thanks to Larry Clegg, alan_at_nabeth.cxo.cpqcorp.net, Richard Jackson,
Dan Riley, Xavier Mertens and Chang Song. Based on their responses, it
seems in general that the situation has indeed changed since 1995, and now
AdvFS is the weapon of choice. We will investigate the AdvFS/cnfs direction
first (once somebody gives me some requirements :-)).
My original question was:
I find myself in the position of possibly having to set up an INN news
server (version 2.3.2) on a Tru64 5.1 system (a DS20). I did this once
before, way back when (1995), and then it was true that one should avoid
AdvFS and use UFS for a news spool. Since then, AdvFS has changed, and INN
has got more article storage mechanisms. Is the AdvFS vs UFS advice still
valid? I'd appreciate the input of anyone running INN on Tru64 as to any
gotchas that I might look out for. TIA,
Responses:
-----------------------------------------------------------------------------
Forget UFS - use only ADVFS - make sure you have all the latest/greatest
patches on your V5.1 system too.
We use ADVFS exclusively for all file systems - Oracle partitions, root,
usr, var of course and everything else.
-----------------------------------------------------------------------------
The core of the problem that AdvFS had with being a news
spool was that it depended on having contiguous space to
grow the data structures used to store information about
files (BMTs). News places a load on a file system that
tends to create fragmentation and steadily create lots of
new files. The data structure used to store information
about BMTs could also only have a limited number of extents.
So, the load that news placed on the file system either
ran it out of contiguous space or exhausted the ability
of the file system to extend the BMT tables.
Each new version since the earliest versions have been
fixing these problems. Early on there were ways to
pre-extend a file system to help support a large number
of files. Then, defragment was improved to help free
up space and eventually was included as part of the base
system.
In V5, they've allow more extents and do a better jobs of
supporting large number of files. I'm guessing that AdvFS
in V5 will be much better at handling a news load then
previous versions.
-----------------------------------------------------------------------------
I have been running INN with AdvFS since March 1995 beginning with
OSF/1 3.2. The only tough problem I have had was in Dec 2000 after I
upgraded from Digital UNIX 4.0D to Tru64 UNIX 4.0G -- the defragment
utility caused problems with the filesystem. I rebuilt the news spool
AdvFS domain and the problem went away.
-----------------------------------------------------------------------------
Depends a lot on the storage mechanism you choose and the number of
articles you'll be keeping, so I'd make those choice before choosing
the file system. For a large feed stored with tradspool I would
probably stick with UFS, but then our news swerver is still 4.0f.
On our news swerver (lnsnews.lns.cornell.edu) we do CNFS and OVDB on
AdvFS (for CNFS, that's one big file per filesystem, since Tru64
doesn't seem to want to mmap raw disk devices) with a small tradspool
area on AdvFS for stuff that "never" expires. That combination seems
to perform quite well, and can handle a much larger volume than
tradspool--the biggest downside is that I can't grep the spool
anymore.
Only gotcha I can remember offhand is you may need to bump
vm:vm-mapentries as INN now makes very heavy use of mmap if
it is available.
-----------------------------------------------------------------------------
We use innd on Tru64. We had some problems but runs fine now:
The server is used as a reader
Overview method: buffindexed
Storage method: cnfs over AdvFS.
About overview: we tried the ovdb patch but too many problems! (corrupted db,
no real support for 64 bits)
About storage: we tried cnfs over raw devices but here too, some problems.
No other performance issue
Tips: run nnrpd as daemon (nnrpd -D) and let innd use port TCP/433. This
improve the overall performance as innd does not need to spawn a new nnrpd at
each connection.
-----------------------------------------------------------------------------
I am no expert in INN server, but I think UFS still has advantage over
Advfs in performance with many small files.
We have also added "delayed" mount option in UFS, in which all metadata
writes are delayed and synched by sync daemon, which helps "makehistory".
This has tremendous performance advantage over regular UFS mount and Advfs.
But if the machine crashed, the "delayed" mounted partition needs to be
newfs'ed (fsck may or may not fix the inconsistency).
And for spool files, where there are many small files are being created
and deleted, UFS still is better (I am not sure if you can use "delayed"
option on these spool files).
-----------------------------------------------------------------------------
Received on Mon Feb 11 2002 - 13:35:25 NZDT