johnf@runx.ips.oz (John F. Baird) (07/10/87)
Here's an interesting one for those of you who haven't come across it. We do a backup, not standalone, from an RA60 user disk to an RA81 system disk, then back onto a new RA60 user disk. This defragments it nicely, but fragments the RA81 quickly. The backup from the RA60 to the system disk is done like this; $ BACKUP DJA1:/IMAGE DUA0:[]RA60.SAV/SAVE/GROUP=0/NOCRC The restore onto the new RA60 is done like this; $ BACKUP DUA0:[]RA60.SAV/SAVE DJA1:/INITIALIZE (That's the background, here's the interesting stuff...) A couple of weeks ago, I stuffed up the RMS default block and buffer sizes. In fact, I set them all to zero, with the command; $ SET RMS_DEFAULT/BLOCK=0/BUFFER=0/SEQUENTIAL They were originally 16 and 2 respectively, and the backup took much much longer than usual. (Which impressed the users greatly, but then again, that's what they are there for!) So then, I changed the command to something a little more generous; $ SET RMS_DEFAULT/BLOCK=124/BUFFER=4/SEQUENTIAL Wow! Was it fast! Here's a table of timings from the restore portion of the backup procedure. The RA60 contained 247924 blocks, in files of an average size of 500 blocks. The RA81 was reasonably fragmented, the save set file was in about two hundered places. /BLOCK /BUFFER Time (Minutes) 16 2 20 0 0 97 124 4 12 So, if you have an application that spends most of its time reading or writing a large sequential file, and you think that it is more important than anything else on the system, have a look at your SHOW RMS_DEFAULT. You'll probably need some more memory though! James Cameron Kilpatrick Green Sydney, Australia via johnf@runx.oz (ACSnet)