Xref: utzoo news.software.b:1192 comp.unix.microport:228
Path: utzoo!mnetor!uunet!husc6!rutgers!ho95e!wcs
From: wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
Newsgroups: news.software.b,comp.unix.microport
Subject: Re: Problem with News when patched at 14
Message-ID: <2060@ho95e.ATT.COM>
Date: 12 Mar 88 05:01:12 GMT
References: <504@wa3wbu.UUCP> <253@lxn.UUCP> <410190420@nwnexus.UUCP> <914@bigtex.uucp>
Reply-To: wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 27
Keywords: System V inode bug

In article <914@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
:On those inodes: Come on people, inodes don't just "disappear".  If they're
:truly being lost by the kernel (highly unlikely), fsck will show it.

	Well, they do, and it's the kernel's fault, and fsck does find
	them again.  There's an obscure System V bug that was
	reported in the news.admin groups a few months back, which
	causes the superblock to think there are zero inodes left.
	It mainly happens when you're shlepping around a lot of inodes at
	once, which is to say it "only" affects netnews.

	On my machine, /usr/spool has its own file system; if it loses
	all the inodes (rare, but it's happened twice in the last 6 months),
	I can kill cron and lp, and umount/fsck/remount the file
	system, without taking the machine down.  It's annoying, but
	better than kicking everyone off.

	Aside from the inode bug, there's also the fact that news just
	*needs* a lot of inodes.  (I'm using double the default number.)
	I've also found it helps to keep $LIBDIR and $SPOOLDIR on
	separate file systems; if they're on the same system and it
	fills up, expire can't run.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various 
# implements of destruction and went off to clean up the tty driver...