How does magtape avoid the stream-of-bytes issue?
Magtape has blocks.
What exactly is a block?
Is it defined as a sequence of bits or as a sequence of bytes?
If its just a sequence of bytes that define a block, I'm not sure I
understand how blocks avoid the stream-of-bytes issue.
At the physical level, what really defines a block is that between
blocks there are inter block gaps which gives the tape drive time to
stop. If the CPU writes one block and then does calculations or (on a
machine with a multi tasking OS), runs someone else's job, the drive
must stop and wait for the next block to be written. Similarly on
reading, but because the drive does not know what will happen on
reading, then it has to provide inter-block gaps even when two block
writes follow on immediately from each other.
Having this physical structure means a tape can ONLY be read as a
sequence of blocks, you cannot just ask for n tape frames arbitrarily.
By the way, tape frames are really defined by the tracks on the tape,
9 track is 8 bits plus parity, 7 track is I think usually 6 bits plus
parity, (1 inch)16 track is 8 bits plus 8 CRC bits, 10 track is 4 bits
plus 6 CRC bits. There are of course many formats for 1/4 inch and 1/8
inch, and helical head formats, there was even a VCR backup system for
Apple ][ which worked with a VHS recorder and these add an extra
physical structure of stripes, though I think these were streaming
drives without CPU control of the tape deck, hence no proper inter-
block gaps, merely unused tape if the CPU could not keep up whilst
writing. Reading was I presume usually of individual files, so
stopping was not necessary.