Tape dumping, Rays epiphany
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