Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.unix.wizards
Subject: Re: Generic Problem with BSD dump/restore
Message-ID: <1307@hoptoad.uucp>
Date: Mon, 17-Nov-86 21:09:28 EST
Article-I.D.: hoptoad.1307
Posted: Mon Nov 17 21:09:28 1986
Date-Received: Tue, 18-Nov-86 01:35:31 EST
References: <992@cbmvax.cbmvax.cbm.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 28

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@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."