Need assistance with afio problem.

[Chip Rosenthal]

In article <446 at yonder.UUCP> michael at yonder.UUCP (Michael E. Haws) writes:
>find /usr /u -print | afio -oZ -L/back/log | dd of=/dev/rct0 ibs=10b obs=1000b
>
>Part way thru the backup, messages appear in the log file something to the
>effect of "File table overflow" repeated many times.  On the console the
>message "Inode table overflow" appears many times.  When the job
>completes the "df" command shows 1000's of free inodes.

Those messages have nothing to do with what's on your disk.  It means
that the fixed size kernel tables which hold active file and inode
information have run out of space.

Try this:

	# pstat | grep '^[^ ]'
	139 active inodes
	39 processes
	126 open files
	# egrep 'NINODE|NFILE' /usr/sys/conf/master
	inodes		NINODE	250
	files		NFILE	250

(Note that you probably need root privs to access the `master' file,
but not to run `pstat'.)

My first guess would be that you are on the hairy edge, and the backup
is overflowing these tables.  If I remember correctly, XENIX is
distributed for 100 active inodes/files apiece.  As you can see, I
upped mine to 250 - and needed to do so badly.  The machine isn't
doing much at the moment and it still needs over 100 apiece.

If you find that this is the problem, run `/usr/sys/conf/configure'
and select option 3 (Files, Inodes, and Filesystems).  Adjust the
inode/file values, and then run `link_xenix' and `hdinstall' (both in
`/usr/sys/conf') to create and install a new kernel.  It is quite
common to have to increase NINODE and NFILE.  NPROC and NCLIST are
the two others which frequently need to be adjusted.

BTW...I don't recognize your `afio' options.  Are you using a hacked
version?  (Or am I using an outdated version???)  Do you realize you
are missing out on the *best* part of afio?  The `-f' option makes
afio scream.  If you are able, junk the dd and use the afio
pseudo-double-buffering.  Also, I'm concerned that the `Z' option
might be compressing the backup.  If this is the case, methinks you
are making a *big* mistake.  For all intents and purposes, if one bit
is corrupt in an LZW compressed file, the following contents are
unrecoverable.  Using compress on backup volumes is penny-wise and
megatons-foolish.

-- 
Chip Rosenthal     <chip at chinacat.Unicom.COM>  |  Don't play so
Unicom Systems Development      512-482-8260   |    loud, Mr. Collins.