disk-to-disk dump/restores (an interesting observation)

[Scott Leadley]

I've noticed a correlation between number of files and dump/restore time
in the past and collected some numbers recently.  Dumping six partitions
from a Sabre and restoring to a Super Eagle (both connected to the same
Xylogics 753), took a little over an hour (dump/restore time only)(*).  I
took the information I collected and ran a regression analysis (I'm not a
statistician, so take this with a grain of salt) and found that the number
of inodes is the strongest predictor of dump/restore time.  The
approximate relationship is:

	minutes of dump/restore time =
		( number of inodes * .0032 ) + ( KB in filesystem * .000063 )

Even though this relationship was found on a Sun 4/753/Sabre/Super Eagle
combination, it may have something to tell us about other systems.  For
instance, this equation could be used to predict that to do a specific
dump/restore (/var, including /var/spool/news) on a Sun 3/451/Hitachi
815/Super Eagle would take:

	inodes = 45674, KB = 199394 

	( inodes * .0032 ) + ( KB * .000063 ) = 160 minutes = 2 2/3 hours
								or
							      73 MB/hour

which is a fairly good estimate (we just did this recently).  Certainly
better than the rule of thumb of 200 MB/hour for disk-to-disk
dump/restores (using two disks) that I've been using previously.  (I used
large files when I created that rule of thumb and accidentally skewed the
performance towards the high end.)  On the other hand, this predicts that
filesystems with ordinary size files (e.g. /usr) would dump/restore at the
rate of ~150 MB/hour.

Don't let the psuedo-accuracy of this equation override your instincts,
but if you are doing a disk-to-disk dump/restore in the future try it out.

	Scott Leadley - leadley at cc.rochester.edu

(*) the command line I was using was:

	# cd /mnt; dump 0sf 100000 - /filesystem | restore rf -