Tape dumping programs for Unix/Linux...

From: Frank McConnell <fmc_at_reanimators.org>
Date: Fri May 3 11:25:06 2002

> Here you are talking about a data tape with fields that make up records
> where the records are all the same size and the fields being varaible
> length inside the record but repeating in all the other records.

No, I am talking about a data tape with a physical structure that can
be interpreted as a sequence of physical records (each of which has a
length) and end-of-file (EOF) marks.

The physical records can be blocks of multiple logical records as well.

There are also inter-record gaps that separate the physical records
and EOFs from each other, and I suppose the information about how long
those are may be of interest to someone too, it just hasn't been of
interest to me yet and I certainly don't see an obvious way to get
that information using common hardware and software.

> But a tape like this, from the days when tapes was used as random
> access devices is not the format of a system archive tape is it ?

Just because tapes were used as random access devices, that doesn't
mean they were always used that way or were particularly good for it.
And a system archive tape didn't need to be structured for random
access.

So, take classic MPE :STORE format. I'm thinking that it defaults to
having a maximum on-tape block (physical tape record) length of 8192
bytes, but that's overrideable by the user and variable in any case.

A single-volume (single-reel) :STORE set has several parts:

(a) two files that could actually contain useful bits if this is
really a :SYSDUMP tape (each is followed by its own EOF, even if
not present); if this isn't a :SYSDUMP tape then there are
two consecutive EOFs at the start

(b) a :STORE label, which is a single 80-byte tape block followed
by an EOF

(c) a :STORE directory, which is written as blocks of up to the
maximum block length; each block contains a number of 24-byte logical
records which give the names of the files to be stored on this
volumeset; again, this is followed by an EOF (Note this presents the
order in which the files are stored on the volumeset)

(d) user files, each of which is written as one 256-byte block
containing a copy of the MPE file label followed by more blocks
of actual file data, and finished off with an EOF (Note I may be
forgetting some things about how user files are written to the
tape; in particular I can't remember how user labels are stored;
Stan may know more)

(e) a :STORE trailer label, which is another 80-byte tape block
followed by three EOFs

A multi-volume :STORE set makes for some additional complexity.
Volumes after the first don't have the two files and EOFs and just
start with the :STORE directory, plus once you get to multi-volume you
also need to deal with whether a file was split across volumes.

OK, maybe I could kinda sorta do this by cat'ing the tape files to
disk files and writing some code to kludge around the lost
physical-record boundaries. I'm not sure about the user files but
I have some ideas to try.

But frankly I'd rather have a container file format and tools to
collect and preserve the information. Then I can treat the container
file like a tape. If I can write some descriptive text in the
container file as well, that would be like sticking a label on the
tape to me.

> If it was me i would spool the whole raw image to disk, and work
> with it there ,, it can certainly be massaged into any format you
> like after that ...

That is what I want too. The problem is, the "raw image" includes
information other than the bytestream. If you use bytestream-oriented
tools like cat, you lose that other information.

-Frank McConnell
Received on Fri May 03 2002 - 11:25:06 BST