Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!mips!skyking!jc
From: jc@skyking.UUCP (J.C. Webber III)
Newsgroups: comp.unix.internals
Subject: Re: Why is restore so slow?(what about using cpio -pudmv)
Message-ID: <173@skyking.UUCP>
Date: 30 Jan 91 13:39:14 GMT
References: <50235@olivea.atc.olivetti.com> <2880@redstar.cs.qmw.ac.uk>
Organization: Skyking Inc., San Jose CA USA
Lines: 40

In <2880@redstar.cs.qmw.ac.uk> liam@cs.qmw.ac.uk (William Roberts;) writes:

>Restore suffers from the fact that files are stored in inode-number order: 
>this is not the ideal order for createing files as it thrashes the namei-cache 
>because the files are recreated randomly all over the place. We reorganised 
>our machine once and used dump/restore to move our /usr/spool and /usr/mail 
>partitions around: /usr/spool contains lots of tiny files called things like 
>/usr/spool/news/comp/unix/internals/5342 and this took an incredibly long time 
>to restore. /usr/mail contains several hundred files but no subdirectories and 
>restored in about the same sort of time as it took to dump. 

I have the imfamous lost inode problem on my system (after installing 
Bnews) so periodically I need to recover my /usr/spool partition.
What I have been doing is using "find . print|cpio -pudmv /new.slice
/usr/spool"  to move the files to a different partition while I clean
up the /usr/spool slice.  I do a rm -r * on /usr/spool, umount it,
fsck it, remount it and the cpio all the files back from the backup
partition.  My purpose in doing all this rather than just a simple
fsck is an attempt to recover *all* stray inodes sprinkled throughout
the /usr/spool slice.  My assumption is that the cpio'ing of these
files will cause them to have their inodes reassigned and layed out
sequencially on the disk.  Is this a correct assumtion?  It seams
to last longer (between "out of inode" messages) than just simply
fsck'ing the partition.  BTW, does anyone know of a resonable fix
for this problem.  I don't have kernal sources, but I can do some
kernel parameter tweeking and rebuilding using the sysconf utilities
on my system.  I have a CounterPoint System19k 68020 SystemV.3.0.
've read some postings about how this bug manifests itself, but
haven't seen anything about how to fix it except to contact the
vendor.  Well, that won't work, CounterPoint is out of buisness.

thx...jc

--
 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 \  J.C. Webber III		jc@skyking.UUCP	                              /
 /  R&D Lab Manager		(...uunet!mips!skyking!jc)                    \
 \  Mips Computer Systems	{ames,decwrl,pyramid,prls)!mips!skyking!jc    /
 /  (408)524-8260                                                             \
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/