dump(8) verification on Zilog

[Tim Radzykewycz]

In article <135 at ucbjade.BERKELEY.EDU> cnrdean at ucbtopaz.UUCP () writes:
>Tom Slezak.  I think you're right.  As a matter of fact, I 
>think the Zilog tape dump programs are programs which were never
>completed:  If I ask restor to recover a file that is on the  2nd
>track, restor first determines what the inode is.  Then it starts
>down the first track to see if that inode is on it.  If it is
>not, it starts down the second track ...  If the inode happens to
>be on the last track, it can take a LONG time to recover a file.
>I don't know why it
>doesn't check the inode at the beginning of each track first.

>If anybody from Zilog reads this, I would appreciate a comment.
>I have been too lazy to call you.

>Sam Scalise

The cartridge tapes in question don't work this way.  The fact
that they seek down the first track, rewind, seek down the
next track,... is not because the program (dump in this case)
isn't finished or doesn't know what's going on.  The fact is
that these tape drives look like normal 9-track tape drives
to the applications.  I'm pretty sure that *even the controller*
doesn't know where the end of a track is and the beginning of
the next.  That is only known by the tape drive itself.

In any case, the fact that a particular file is located on
a particular track of the tape is invisible to the applications.
-- 
Tim (radzy) Radzykewycz, The Incredible Radical Cabbage
	calma!radzy at ucbvax.ARPA
	{ucbvax,sun,csd-gould}!calma!radzy