17 Sep
2020
17 Sep
'20
8:56 a.m.
On 09/17/2020 12:29 AM, shadoooo via cctalk wrote:
Hello,
I have a question about 9 track tapes and block sizes.
What I know is that tape is subdivided in files by means of marks, and each
file is subdivided in blocks of equal size.
This is not necessarily true. Many
systems can handle "VBS"
(Variable Block Sequential) tape files.
But, yes, fixed block size is more common.
Programs like tar use a specific block size to create
files on tape.
However files can have different block sizes like bootloader file,
installation dumps and root file system copy on 2.11BSD.
Now suppose you find and unknown tape you want to preserve: using dd you
could easily 1:1 copy tape files to hard disk files using a SCSI drive and
Linux.
But: how you know which block size is on the tape?
OK, the tape formatter will know, and signal the system when
reading. So, you would issue a read command to the OS,
giving a block size at least as big as the biggest block you
expected to see.
The formatter/interface would report the number of bytes in
that block.
Now, when putting a tape image into a disk file, that gets
more complicated. There are various "tape container file"
schemes where the block size is encoded into the data in
some form. If the tape just contains a single file, it may
not matter as the data is just a stream of bytes. But, if
the tape contains multiple files, then it is pretty
important to preserve the record lengths and file marks.
I'm a lot more familiar with IBM and DEC tape formats, and
had my own container file format to process disk images of
tapes. Unix systems support all these options in one way or
another, but tar tapes are just a stream of bytes, and I
don't think the block size has much effect.
Jon