Generic Problem with BSD dump/restore

[John Gilmore]

I too had an odd experience with dump/restore recently, on a Sun-3/160
running Sun Unix 3.0.

I was getting a variety of errors on one of my SCSI 71 meg disks
containing /usr/spool, and decided to reformat it.  I also wanted to
reduce the number of inodes in /usr/spool -- I overrode the default
formula to provide more inodes for the large number of short files
(news articles).  Turns out that I never got above 5 or 10% inode
usage, and I wanted to reclaim some of that space.  I run this
partition at 4K blocks, 512 byte frags to reduce wasted space.

I took the system down to single user, ran fsck on the partition, did
an incremental dump of it (I had a fulldump, also done single user,
from a month before), reformatted it, did a new mkfs on it (being less
generous with inodes), and did a restore of the full dump and
incremental dumps.  The restore ran really incredibly slowly -- many
hours to restore a partition that took 25 minutes to dump.  It
complained about two or three missing files (individual articles in
/usr/spool/news) but I kept telling it to continue doing its best.  It
completed successfully, and I had about 10 megs more free space due to
fewer inodes.

   *	Why did restore complain about a few files, when the dumps were
	both taken on quiescent, fsck'd file systems?
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore at lll-crg.arpa
    "I can't think of a better way for the War Dept to spend money than to
  subsidize the education of teenage system hackers by creating the Arpanet."