Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!world!geoff
From: geoff@world.std.com (Geoff Collyer)
Newsgroups: news.software.b
Subject: Re: i-nodes and Cnews (really pre-SVR4 and C News)
Message-ID: <1991Apr8.203030.7210@world.std.com>
Date: 8 Apr 91 20:30:30 GMT
References: <1991Apr7.194503.22015@techbook.com>
Organization: Software Tool & Die Netnews Research Center
Lines: 30

James Deibele:
>we're running System V R3.2 and the i-node limit for a file-system seems
>to be locked around 64K.  I can set higher values, but they don't work.
>I've heard that people get around this by patching Cnews so that it will 
>recognize directories on different file-systems.

If your system supports symbolic links, you don't need to change C News
at all; just mount the other file system(s) in appropriate places (e.g.
under /usr/spool/news, or elsewhere with symbolic links from under
/usr/spool/news).  C News will create symbolic links as necessary under
/usr/spool/news.  You will need to invoke expire with -l though.

If you have a pure System V that lacks symbolic links, help is on the way.
At least one person has already modified C News to copy files to implement
cross-posting.  Something similar will probably become official (though
it's going to make spacefor more complicated).

>Does it make a difference if the file-system is mounted via NFS?  

Yes, you can encounter all the usual problems due to a downed file server
or due to NFS not implementing Unix file system semantics.  If you don't
mind various components of the news system hanging or getting "disk i/o"
errors when a file server goes down, the former is not a problem for
you.  We have tried to deal with the latter, but are rethinking that
decision:  using fsync() to force NFS to report i/o errors is more
expensive than we like, and running relaynews (and possibly the input
subsystem) anywhere but on the machine with the news file systems is
asking for trouble (and will be slow due to synchronous NFS writes).
-- 
Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff