Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.sys.sequent
Subject: Re: Running out of inodes
Message-ID: <7041@cbmvax.UUCP>
Date: 2 Jun 89 14:31:22 GMT
References: <1033@syma.sussex.ac.uk> <193@sopwith.UUCP>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 31

In article <193@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes:
> In article <1033@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes:
> 
> |Trouble is, we find that no matter what number is supplied with the -i
> |option to newsfs, the file system is rebuilt with exactly the same
> |number as before (i.e. 36864 inodes on a 254Mb partition)! We asked for
> |twice the current number of inodes.
> 
> Sounds odd.  As a workaround, you could try running newfs -v to get
> all the magic numbers, and then running mkfs directly, tweaking the
> 'nbpi' argument as desired.  Unless Sequent has done something unusual,
> newfs is merely a friendly front-end to mkfs.

With Ultrix (also 4.2 BSD based) I ran into the same problem maybe two
years ago.  It turned out there was an upper limit on the number of inodes
for a given blocksize/fragsize and the only way to get more inodes was to
diddle these values.  There was also only a restriction on blocksize.

Trying to use imaginative values resulted in them being silently ignored
and the default values being used.

It's been long enough I wouldn't swear by any of this, but maybe it'll
point you in the right direction.  Read the fine print in the manual and
play with newfs -v and dumpfs to see what you're really getting...

					George

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)