Archive Tapes

[Bradley W. Fisher]

In article <29490 at cup.portal.com>, Dante_A_Nicolello at cup.portal.com writes:
> I am having two problems with an Archive 60 meg Fastape.
> My setup:
>         25mhz 80386 w/cache
>         isc/386/ix 2.02
>         Adaptec SCSI adapter w/ scsi HD
> 
> Problem one:
>         Tape does not stream. It runs for about 3 seconds, stops.
> Then the HD reads more data, then the tapes rewinds a little and
> goes another 3 seconds and this repeats. This makes backing up take
> a long time. I have tried both tar and cpio. I noticed that if I
> make the buffer size in cpio 51200, it seems to write more data at
> a time. 
 
After playing around with some commercial backup packages lately, I 
have noticed and tried to solve this same puzzle myself. In fact I had 
made a post to the net about a month ago asking why it was that SCO XENIX
tape drivers were able to backup to tape so much faster than 386ix,Altos,
NCR, etc. Unfortunately, no one responded.

My own conclusions are basically what you were told ...

> Interactive tech support just told me to adjust the buffer size.

... things do revolve around the buffer size. As I understand it, this is 
the amount of data transferred from origin to ram before it is transferred
to the final destination. Also, as I understand it, this has been declared
by AT&T source license code to be 10k (or 20 - 512 byte blocks,hence the
usual blocking factor of 20) for tar. This was probably quite adequate for 
older start/stop reel and cartridge systems.

Various companies that have licensed the source to *NIX either have or have
not addressed this problem, and hacked the source for tar to increase the 
buffer size. It seems Interactive falls into the latter category. However,
SCO falls into the former ... their "blocking factor" of 20 *I beleive* is
really a multiple of ten ... and about 100k is being tranferred at a time.
With less stops for transfer of data this results in an overall rate increase.

> The question is, can it read from the disk and write to
> the tape concurrently?

Now for the clincher ... how do you keep it streaming? Well, going out to
tape(the slowest device in the picture) you would ideally fill one ram buffer
area with data from the disk and feed it to another ram buffer area (are we
talking pipes here?) that is in control of feeding the tape drive. I think 
from what I've read, that to be able to do this involves the use of "shared
memory", and in brief I've also been told "you can't do that with the Intel
achitecure". But I'm rapidly stepping out of bounds on my knowledge 
of how all this works ... perhaps a someone with a greater understanding 
of the "internals" could step in now and give us all a clearer picture.

> Problem two:
>         When the tape reaches the end of the cartridge, not the end of the
> current track, unix produces a "write() error" instead of prompting
> me to switch tapes.

In tar you'll need to use the "k" option to tell it the size of the media
you're using ... eg. tar cvbfk 20 /dev/rct0 60000 for a 60 mb tape under
SCO XENIX.

I'm just a wanna be UNIX guru (IJWBUG)               | Micro Maintenance, Inc.
						     | 2465 W. 12th St. #6
	-== Brad Fisher ==- 		             | Tempe, Arizona  85281
...!asuvax!mcdphx!hrc!microm!bradf!brad		     | 602/894-5526