Tape dumping, Rays epiphany

From: Raymond Moyers <rmoyers_at_nop.org>
Date: Thu May 2 23:56:39 2002

To Wit

 (about dd blocking handling)

 The original need for dd came with the 1/2" tapes used to
 exchange data with other systems and boot and install Unix
 on the PDP/11.
  Those days are gone, but the 9-track format lives.
 To access the venerable 9-track, 1/2" tape, dd is superior.

 With modern SCSI tape devices, blocking and unblocking are no
 longer a necessity, as the hardware reads and writes 512-byte data blocks.

 ( what i was familiar with )

  However, the 9-track 1/2" tape format allows for variable length blocking
 and can be impossible to read with the cp command.
 The dd command allows for the exact specification of input and output block
 sizes, [[and can even read variable length block sizes, by specifying an
 input buffer size larger than any of the blocks on the tape.]]

  (Stan was right on target here eh ?)

 Short blocks are read, and dd happily copies those to the output file
 without complaint, simply reporting on the number of complete and short
 blocks encountered.

 Murphy's Law was postulated long before digital computers,
 but it seems it was specifically targeted for them.
 When you need to read a floppy or tape, it is the only copy in the
 universe and you have a deadline past due, that is when you will
 have a bad spot on the magnetic media, and your data will be unreadable.
 To the rescue comes dd, which can read all the good data around the bad
 spot and continue after the error is encountered. Sometimes this is all that
 is needed to recover the important data.

Example dd bs=265b conv=noerror if=/dev/st0 of=/tmp/bad.tape.image

 Yup .. using cat to do the same thing, it gets the err signal and
 drops, but dd can be told to ignore it

 So in this case its clearly superior, and the *only* tool for 9 track tapes,
 ( due to the block handling )

 So i stand before you better educated. thx to those that filled in the
 missing bits

 Raymond
Received on Thu May 02 2002 - 23:56:39 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:20 BST