2 May
2002
2 May
'02
4:54 p.m.
At 04:10 PM 5/2/2002 -0400, Douglas H. Quebbeman
wrote:
???
I just did a 'dd' of a bad QIC-80 tape; it read the entire tape
as a single file, and didn't bail out.
I've not done that with magtape, but ISTR someone else here
saying that 'dd' does raw reads, bad blocks and all...
My bad if not true.
-dq
No. And I see no useful purpose in including that
in the format.
If the read was recovered, you have the data; surely you would
*not* want to recreate a tape and make a previously marginal
block, marginal again on a clone?
Choosing between the loss of all the data, and a partial
copy, I'll take the partial copy.
I have many 8-inch disks with bad blocks. I'd like to preserve
the data if at all possible. A simplistic 'dd'-style read
won't preserve everything; it'll bail out when it has a problem. 
2 May
2 May
5:23 p.m.
On Thu, 2 May 2002, Douglas H. Quebbeman wrote:
I just did a 'dd' of a bad QIC-80 tape; it
read the entire tape
as a single file, and didn't bail out.
I've not done that with magtape, but ISTR someone else here
saying that 'dd' does raw reads, bad blocks and all...
My bad if not true.
No bad, just an honest difference in perspective. I recently went
through this with a set of VMS-based diagnostics tapes. AFAIK, the
tapes are undamaged, but dd returns a valid read - of the first file on
the tape - and stops. I'm not that familiar with non-"streaming"
formats, so I just accept what is without knowing why....
dd on a disk or raw filesystem ignores files. On a tape archive, even
using the raw device as the if, dd reads files and stops at the end of
the first record.
cat just dumped useless gibberish to a file. catting the file back to
tape "should have" worked, right? Nope.
Doc
6:15 p.m.
On Thursday 02 May 2002 21:23, you wrote:
No bad, just an honest difference in perspective. I
recently went
through this with a set of VMS-based diagnostics tapes. AFAIK, the
tapes are undamaged, but dd returns a valid read - of the first file on
the tape - and stops.
and if you are using the /dev/nst0 device .. ( the one that dont rewind )
then you repeat the command for the second file, dumping to a new file
repeat for all the files on the tape, the last one i did this way, all
the files spooled off the tape turned out to be Z compressed cpio
archives that i could then extract the usual way
I'm not that familiar with
non-"streaming" formats, so I just accept
what is without knowing why....
Certainly less stressfull to accept and work around than to tilt
at windmills ;=)
dd on a disk or raw filesystem ignores files. On a
tape archive, even
using the raw device as the if, dd reads files and stops at the end of
the first record.
Yes.
cat just dumped useless gibberish to a file.
cat dumps byte for byte exactly what comes off the tape, the "gibberish"
could be Z compressed for example
use the
file - determine file type
and see if it has a known magic number
catting the file back to tape "should have"
worked, right? Nope.
No, but ... did you look at the mt command ?
such as eof, weof Write count EOF marks at current position.
After closing the write with the mt eof command it will probably work then.
all with the nst0 non rewinding device that allows you to directly control
things like tape position, and where at tape stop it will maintain this
position.
Raymond
5:56 p.m.
On Thursday 02 May 2002 20:54, you wrote:
I just did a 'dd' of a bad QIC-80 tape; it
read the entire tape
as a single file, and didn't bail out.
I've not done that with magtape, but ISTR someone else here
saying that 'dd' does raw reads, bad blocks and all...
That may be the behavior of the qic driver, where err detection
(and just about everything else) is pushed up into userspace.
A Dat or a DC600 scsi will often bail out, sometimes the device
itself will stop (DAT) and your desire to have it keep marching
onward is thwarted.
if the tape and driver is well behaved you can usually use the mt
command to move down the tape to the next record and go
back to spooling off your files making a note to go back
and try the bad one again.
some of the poorly behaving DAT drives fall down so badly as to
need a reset or eject reload to get em talkling again.
You really have me going about the 9 track behavior tho
null portion of tape as record delimiters "crap in the gap"
problems of the past, and other such things.
So far what ive learned about those things is nothing as
many years around this stuff conditioned me to expect.
If i spool the whole raw tape using a driver that knows
nothing of any null gaps and simply spool all bytes that
are bytes to a file .... could not i then pull the desired content
out of the spool if i knew the format of the data ?
If random access is what they are doing, how did they deal
with a rewritten record, pad the unused portion of the record
to overwrite trailing garbage ? or was the bytecount in a rewritten
headder so that the controller knew the valid byte count ?
a tape with blank as delimiter/filler and records with no or
painfully terse descriptors seems to me very .... um something.
8121
days inactive
8121
days old
3 comments
3 participants
participants (3)
-
doc＠mdrconsult.com -
dquebbeman＠acm.org -
rmoyers＠nop.org