thomas@utah-gr.UUCP (Spencer W. Thomas) (11/14/83)
You didn't mention which Unix version you are running. I know that on 4.1Bsd the restor program spent upwards of 50% of its time just clearing out (and copying?) buffers. Write, or steal, a buffer clear/copy routine in assembler, and you'll probably see much better improvement. Our full saves are up to 26 tapes now! (We've got a 6250bpi tape drive on order, and will soon switch to 4.2, which should help too.) =Spencer
brown@kpno.UUCP (11/18/83)
We're running 750s with RA81s and TS11s. Doing a level 0 dump on the 160Mb
user partition has become a royal pain now that the user space is 90 % full.
The full dump takes 4 tapes and is slow! Even switching to 125 ips
tape drives will still take 4 tapes but at least go faster. A thought is to
divide the partitions which are backed up into ~40 Mb partitions so each will
fit on a single 2400' 1600 bpi tape. Are there any reasons not to do this?
I'd appreciate any experiences/war stories etc. and will summarize after a
week or so.
regards,
Mike Brown Kitt Peak National Observatory
Tucson, Arizona (602) 325-9249
{amd70,arizona,decvax,floyd,fargovax,hao,ihnp4,lbl-csam,
sdcarl,sdcsvax,seismo,unc,utastronomy,ut-sally} !kpno!browndmmartindale@watcgl.UUCP (Dave Martindale) (11/29/83)
4.1BSD restor (and V7, for that matter) is rather slow because of the way it spends so much time copying data around. But "dump" is much more careful about this thing; it even sorts the data blocks which are to be read for any particular tape block to speed things up. Once you get a 6250 BPI drive, you will find that dump spends the vast majority of its time reading disk, not writing tape. Splitting a large filesystem into smaller ones won't help this any. 4.2BSD's larger block sizes and more careful disk layout should speed things up considerably though.