2 Jul
2005
2 Jul
'05
9:37 p.m.
However, if I try to READ a file, and I've tried
this with dd and
Eric Smith's tapedump utility and whatnot, it always returns with
0 files read. It apparently sees the file marks as it will say its
reading file 1, file 2, etc., but it never actually dumps anything.
I've tried the multiple tapes at multiple densities and they are
tapes I've read before on another system.
Any idea what block size was used to write the tapes? Any relevant
messages in the kernel log (i.e. output of "dmesg")? Which /dev/device
are you using to access the drive? What's the dd command you're using?
WTF???
Sounds like _my_ life. :-)
De
3 Jul
3 Jul
12:59 p.m.
On Sun, 3 Jul 2005, Dennis Boone wrote:
The block and record sizes are written on the tape label: 80 and 3200
respectively. However, adding these to the command line options don't fix
anything.
The dd command I used is simple:
dd if=/dev/st0 of=tape.img
I've since learned that I want to use the /dev/nrst0 device handle so that
the tape does not rewind after every file operation. That's handy, but
doesn't solve the problem.
I tell ya, I can understand that complicated shit will take time, but when
something that should be easy gives me more grief than the most difficult
things I've ever worked on, it makes you wonder.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
However, if I
try to READ a file, and I've tried this with dd and
Eric Smith's tapedump utility and whatnot, it always returns with
0 files read. It apparently sees the file marks as it will say its
reading file 1, file 2, etc., but it never actually dumps anything.
I've tried the multiple tapes at multiple densities and they are
tapes I've read before on another system.
Any idea what block size was used to write the tapes? Any relevant
messages in the kernel log (i.e. output of "dmesg")? Which /dev/device
are you using to access the drive? What's the dd command you're using? WTF???
Sounds like _my_ life. :-) 
1:16 p.m.
On 7/3/05, Vintage Computer Festival <vcf at siconic.com> wrote:
I tell ya, I can understand that complicated shit will
take time, but when
something that should be easy gives me more grief than the most difficult
things I've ever worked on, it makes you wonder.
Well... termination and cable issues aside, I don't have any obvious
things to recommend. I know that in my case, I got a DEC TSZ07,
pulled out an Adaptec 1640 PCMCIA SCSI card, plugged it all together
and was instantly dumping tapes onto my RH9 laptop.
I think others have suggested some good things - test the SCSI chain
with a hard disk, then add the tape drive. Perhaps try a different
external cable. I've had those go bad on me every once in a long
while.
If you can get bits at all, it's no longer a pass/fail problem - it's
one of those harder-to-track down problems upon which some wierd
variable (phase of the moon, etc) is influencing. Not talking at all
is much easier to solve.
SCSI voodoo... remember, it _used to_ be hard to get some things
working. Tape drives never got the same attention as disk drives, and
it's less unexpected to fall into a pit trying something new.
-ethan
1:20 p.m.
Vintage Computer Festival wrote:
The dd command I used is simple:
dd if=/dev/st0 of=tape.img
I've since learned that I want to use the /dev/nrst0 device handle so that
the tape does not rewind after every file operation. That's handy, but
doesn't solve the problem.
That also only reads 1 record from the tape. I've had good luck with
Michael Sokolov's tape utilities (mktape?), and not-wonderful luck in
general extracting non-Unix tapes in Linux. NetBSD or FreeBSD tend to
be a little less idiosyncratic about the tape devices themselves.
You may also, depending on your SCSI adapter and the tape drive, need
to tell the drive either the block size explicitly (each time it
changes) or set it to variable. If I'm having trouble reading a stacked
tape (multiple files), that's usually the problem. And in Linux, YMMV
with the variable setting.
I tell ya, I can understand that complicated shit will
take time, but when
something that should be easy gives me more grief than the most difficult
things I've ever worked on, it makes you wonder.
I think the "should be easy" part was the crucial mistake. ;)
Doc
7429
days inactive
7429
days old
3 comments
4 participants
participants (4)
-
doc＠mdrconsult.com -
drb＠msu.edu -
ethan.dicks＠gmail.com -
vcf＠siconic.com