Problem with News when patched at 14

[Geoff Kuenning]

In article <3adab345.b8ab at apollo.uucp> rees at apollo.uucp (Jim Rees) writes:

> 	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.)
> 
> If you had an Apollo with the Domain/OS file system, you wouldn't have
> this problem.  If it runs out of inodes, it just allocates more out
> of the free list.  This shouldn't be too hard to hack into your kernel,
> too.

This is not impossible on System V, but you can't just grab them from the
free list.  The kernel assumes (for speed) that the inode list is contiguous.
So you'd have to grab the first block or blocks immediately following the
i-list.  Assuming it was occupied by something useful (originally, it would
be the root directory) you'd then have to grab a block off the free list
and relocate the grabbed block there.  Then you'd have to locate whichever
i-node or indirect block pointed at it, and redirect to reflect the relocation.
(Got that?)

The code isn't actually very complicated, but the kernel would have to shut
down the affected filesystem for the duration, and on a large
filesystem the search for the guilty indirect block would take quite a while.

Fortunately, I've forgotten most of the details of the BSD not-so-fast
filesystem, so I can't comment on whether BSD could implement something
like this.

(Besides, this is soooo un-Unix-like.  Next you'll be wanting to expand
kernel tables as necessary, or even swap space.  Whatcha want, a
20th-century operating system? Egad! :-)
-- 
	Geoff Kuenning   geoff at ITcorp.com   {uunet,trwrb}!desint!geoff