leadley@uhura.cc.rochester.edu (Scott Leadley) (10/08/90)
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@cc.rochester.edu (*) the command line I was using was: # cd /mnt; dump 0sf 100000 - /filesystem | restore rf -