How to read data from magnetic tapes and playing the detective with octal dump - Part 1

8 min. read

Caution! This article is 11 years old. It may be obsolete or show old techniques. It may also still be relevant, and you may find it useful! So it has been marked as deprecated, just in case.

This post is part of a series of three posts. Check them out!:

I believe that you learn faster when there is a purpose to what you are doing. Learning to work with very old magnetic tapes led me to learn about octal dump, a command I would have probably never used if not for these tapes.

A bit of context

For the first part of my thesis work, I had to analyze old GSI data (measurements from back in 1996 and 2000). At the time, they were using a VAX/VMS data acquisition and analysis system called GOOSY. There is a paper about it, "GOOSY-VME: the data acquisition and analysis system at GSI" if you're interested, and the old GOOSY pages can be found in a time capsule for web pages at GSI. Finally, if you are interested in what the place where these measurements took place look like, check out the setup page of the FRS, a fragment separator that was part of GSI, at Frankfurt, Germany. My favorite picture there is the panic button. Can you find it?

So basically it was very important to store the data in a modern system, if possible, digital, since the data was stored in tapes. In MAGNETIC TAPES. Imagine! I'm a nostalgic though, so I had a lot of fun with it.

To read the tapes we had a big gray box that looked like an old Nintendo NES, and you had to introduce the tapes (which were a TK50 model, I think) as if it was a VHS. The driver was connected to my tower through a huge SCSI cable like those you used on ancient printers.

Somebody posted a video on Youtube showing how this all looked like. For several months, this was my life, funny noises included:

The not-so-fun part of it was that our workstations were not really "owned" by each team member, but more like "servers" that were on 24/7 so that anybody could connect through ssh. There was only one tape driver and it was the one attached to MY workstation, so I found myself receiving calls and emails from team members in other offices (or even countries), with requests like: "Hey, when you are finished reading your tape, put this other tape with the alpha measurements". And they manipulated the tape from the distance.

Instructions for manipulating TK-50 tapes

As shown in the video, when you introduced the tape in the driver, two leds started blinking. One of them was an indicator of an error, and it was the first thing you had to look at, because these tapes were very old and weren't kept in the best conditions. Many of them were damaged and you could not even mount them. In some of them the tape was acually sticked and merged together due to heat and humidity.

If everything was OK though, I would start my tape-recovering duties using the mt ("magnetic tape") command. My workflow looked more or less like this:

  • Check the tape's status. For example, if the tape driver was mounted at /dev/nst0: 
    
mt -f /dev/nst0 stat
  • Read a file from the tape. The dd command was used for this task: 
    
dd if=/dev/nst0 of=you-name-it bs=16K

    where if stands for "input file", of is "output file", and bs is the "block size".

    In my case, for each file I had to recover three files: a header file, the actual data, and the end of file. In VME/VMS the three were stored in one single file, but our version of Linux at the time (Scientific Linux touched by CERN touched by my research institute's tech department) broke that into three.

  • Jump a number of files (a tape drive provides sequential access storage). To jump 5 files forward: 
    
mt -f /dev/nst0 fsf 5

    To jump 5 files backward:

    
mt -f /dev/nst0 bsf 5
  • Before taking the tape out, ALWAYS rewind (just like VHS!): 
    
mt -f /dev/nst0 rewind

    or you could also use the button in your driver, if your model comes with one.

When you were finished dumping a tape's contents, you had to check with the VMS list that all the files were in there, and mark the files that were corrupt. Examples of corruption are: failure before the EOF, header or EOF missing, half of a file only and the other half unreadable (they were big files, 100-500 Mb), in/out general errors, etc.

And that's pretty much what I did with the tapes. Now let's see why we needed octal dump. Wasn't it all written in a human friendly way? Couldn't I just open a file in my text editor or spreadsheet?

HAHAHAHAHAHA... No.

Find out in Part 2.

Comments