NFS support

Alex Kiernan alexk at
Thu May 23 12:36:31 UTC 2002

I'm not convinced inn-committers isn't still eating my commits, so to
be sure, I've just committed this change:

Add three new options to inn.conf:

nfswriter: assume the spool is on NFS mounted storage and use explicit
msync()s to try and force data out in a timely manner

nfsreader: assume the spool is on NFS mounted storage and use explicit
msync()s to try and invalidate data before using it to ensure up to

tradindexedmmap: don't use mmap() for tradindexed, read the data

tradindexedmmap corresponds to what what #ifdef NFSREADER and more
accurately describes what it does.

We also fix a bug in what was the NFSREADER code so we don't allocate
4 times as much ram as we need to read the overview in (the code was
allocating a pointer's worth of storage for every byte it needed to
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS: Committing in .
CVS: Modified Files:
CVS: 	doc/pod/inn.conf.pod include/innconf.h include/libinn.h 
CVS: 	lib/getconfig.c samples/ scripts/ 
CVS: 	storage/cnfs/cnfs.c storage/ov3/ov3.c 
CVS: 	storage/tradindexed/tdx-data.c storage/tradindexed/tdx-group.c 
CVS: ----------------------------------------------------------------------

Using a combination of nfsreader and nfswriter we're successfully
running a single writer onto a shared NFS filestore and a bunch of
readers working off of it (all Solaris).

I was going to use the NFSREADER code until I figured out what it was
actually doing, but I'd already separated it into a config option

I also changed the code in ov3.c (which I forgot to put in the commit
message) so that it used the permissions which were requested for the
overview rather than relying on the NFSREADER voodoo.

Alex Kiernan, Principal Engineer, Development, Thus PLC

More information about the inn-workers mailing list