MHJohnson@HI-MULTICS.ARPA (Mark Johnson) (03/04/86)
Our site has 4-RA81 disks and were having problems with balancing disk usage across the drives. We recently created a 3-disk volume set for all our user files and the following occurred: (1) Backed up our disks with BACKUP/NOCRC/BUFF=5/IMAGE/FAST/BLOCK=16000 etc. This operation on our TU78 at 6250 bpi took between 1 and 2 hours per disk drive. Our main user disk had about 50k files with heavy fragmentation and took the longest. (2) Created the volume set (INIT times 3) and MOUNT/BIND to make the volume set. While we were at it, we rebooted to checkout our system startup to make sure it was ok. (3) Restored the files onto the volume set. The same sort of backup command was used as for the save (BACKUP/NOCRC/BUFF=5/FAST...) except /IMAGE was omitted. Well, things got very boring when the system took about an hour and a half (!!!) per tape (that is well over 3 hours per disk) to restore the files Needless to say, staying up until 1:30am because the restore operation turned out to be much slower than the save operation is not my idea of fun. If someone out there (is Andy listening?) has an idea why the restore took so much longer than the save, I'd like to hear about it. Of course, if you want to do this sometime, you'd like to know too. --Mark <MHJohnson @ HI-MULTICS>
jl%dac.triumf.cdn%ubc.CSNET@CSNET-RELAY.ARPA (John Lloyd) (03/11/86)
Ahh you were caught by the Backup non-Image performance crunch. Backing up disks /IMAGE is considerably faster than /NOIMAGE, because Backup goes by the Index file rather than the directory structure. Your restore took so long because you chose the wrong method: 1) Back /image /noinit tape: disk1:,disk2:,disk3:,... would have been faster than your 2) Back /noimage tape:[*...] disk1:[*...],disk2:,disk3:,... which requires many references and re-references to the index file and various and sundry directories each file creation. Note that method (1) requires disk1:... to be mounted /Foreign, thus Backup keeps the directories and allocations problem to itself; while (2) requires the XQP to do the work, and of course XQP is not optimized for file restores from Backup. Live and learn. I haven't decided myself if a disk copy (RM05 to RA81) is faster to use /Image backups to tape and back to disk, or if I should just wait for the Backup RM05:[*...] RA81:[*...] to wind its way through the mud.