Skip to content

Instantly share code, notes, and snippets.

@bitsgalore
Created July 3, 2019 22:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bitsgalore/4e8d9a1a60100ceaf28cc3871f4bf263 to your computer and use it in GitHub Desktop.
Save bitsgalore/4e8d9a1a60100ceaf28cc3871f4bf263 to your computer and use it in GitHub Desktop.

Reading a tape with dd and mt

In the simplest case, reading data from a tape involves nothing more than a dd command line such as this one:

dd if=/dev/nst0 of=file0001.dd bs=16384

Here, the "if" argument tells dd to read input from the non-rewind block device /dev/nst0, and the value of "of" defines the file where output is written. The "bs" argument defines a block size (here in bytes), and this is where the first complication arises. The actual value that must be used here depends on the software that was used to write the tape, and its settings. If dd is invoked with a value that is too small, it will fail with a "cannot allocate memory" error. After some experimentation I was able to establish the block size using the following iterative procedure:

  1. Starting with a block size of 512 bytes, try to read one single record (and direct the output to the null device, as we don't need it):

     dd if=/dev/nst0 of=/dev/null bs=512 count=1
    
  2. Position the tape 1 record backward using the mt tool (this resets the read position to the start of the current session):

     mt -f /dev/nst0 bsr 1
    
  3. If step 1 raised an error in dd, increase the block size value by 512 bytes, and repeat from step 1.

Repeating these steps until dd exits without errors will yield the correct block size. Re-running the dd command at the start of this section with this value will recover the first session on the tape to a single output file. This leads to a second complication: a tape may contain additional sessions. We can test for this by positioning the tape 1 record forward with the mt tool:

mt -f /dev/nst0 fsr 1

If the mt call doesn't result in an error (i.e. mt's exit code equals zero), at least one additional session exists. In that case we use mt again to position the tape 1 record backward (the start of the second session). We then repeat the block-estimation procedure for the second session, and read the data with dd.

All of the above steps are repeated until mt's fsr command results in a non-zero exit code, which means no additional sessions exist. The end result is that for each session on the tape we now have a corresponding output file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment