Re: Reading Irix DAT tapes under RH9

[Russell Whitaker <whitaker best com>]

This is a followup to the quoted message below, which I'd sent to the redhat-list 12 days
ago.

Apart from an encouraging note from listmember Sid Cowles, who had privately and graciously
offered to read my tapes on his SGI box (which I declined with thanks), I was surprised that no one
on this list had anything to say on the matter.

So, I did some digging around, starting first with the reference anyone serious about sysadmin
should consult right away:

Unix System Administration Handbook, 3rd Edition
http://www.amazon.com/exec/obidos/ASIN/0130206016/survivalarts-20

I then consulted the Linux edition by the same core writers:

Linux Administration Handbook
http://www.amazon.com/exec/obidos/ASIN/0130084662/survivalarts-20

After that, I finally consulted the book which seems to have given me the critical
clues I needed (those clues being "IRG [interrecord gap]" and "reading past the IRG to
determine block size"):

UNIX Backup and Recovery (O'Reilly & Associates)
http://www.amazon.com/exec/obidos/ASIN/1565926420/survivalarts-20

The sharp-eyed will note that I have indeed tagged those URLs with merchant
IDs (mine).  If you find this writeup to be useful, please use those URLs to visit Amazon
and *buy those books* if you haven't already.

OK, here's what I did...

I have 3 classes of tapes written 9 years ago with tar, cpio, and bru.  First, those tapes
I'd originally written with 'tar cvBf /dev/tape' on my Irix boxes:

1.) Check status of tape:

[localhost]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (45010000):
 BOT WR_PROT ONLINE IM_REP_EN

2.) Set block size of tape to "0", which really means "variable":

[localhost]# mt -f /dev/st0 setblk 0
[localhost]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (45010000):
 BOT WR_PROT ONLINE IM_REP_EN

3.) Find actual blocksize of tape.  Start by feeding 'dd' a blocksize you think is larger than the
blocksize of the tape, and try to read that length of data off the tape.  'dd' will read - and this
is the important part - until it reaches the first IRG (interrecord gap) and then will stop
reading to disk.

[root localhost test]# dd if=/dev/st0 of=testfile ibs=64k count=1
dd: reading `/dev/st0': Cannot allocate memory
0+0 records in
0+0 records out

That's a strangely worded failure.  After a lot of Googling, I determined that
the "Cannot allocate memory" message, in this instance, is associated simply with my
having selected a blocksize too small: I needed to specify a larger blocksize.  So:

[localhost]# dd if=/dev/st0 of=testfile ibs=128k count=1
dd: reading `/dev/st0': Cannot allocate memory
0+0 records in
0+0 records out

Still no joy.  Double it, then:

[localhost]# dd if=/dev/st0 of=testfile ibs=256k count=1
1+0 records in
512+0 records out

Apparent success!  Let's see:

[localhost]# ls -l testfile
-rw-r--r--    1 root     root       262144 Sep 28 15:01 testfile

OK, file's there.  Let's see if I could have used the next smallest blocksize and still
have been successful:

[localhost]# dd if=/dev/st0 of=testfile2 ibs=255k count=1
dd: reading `/dev/st0': Cannot allocate memory
0+0 records in
0+0 records out

No.  So, it looks like 256k was exactly the right number. 

Let's confirm that what I wrote 9 years ago on the tape's paper label is true
(i.e. that I'm looking at a 'tar' archive):

[localhost]# file testfile
testfile: POSIX tar archive

Cool.  Knowing what type of archive I have, and what its blocksize is, I try this:

[localhost] # tar -b 512 -xvf /dev/st0

... and it works!  The argument "-b 512" means "using a blocksize of 512 x 512bytes".

Now for the tapes I had written with 'cpio -ovBc -O /dev/tape', also about 9 years ago:

After ejecting the old tape, putting in the 'cpio' archive tape and confirming that the
device is at BOT (beginning of tape) and still set to variable block size ("0"):

[localhost]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (45010000):
 BOT WR_PROT ONLINE IM_REP_EN

As a shortcut to determining blocksize for this tape - on the assumption that I didn't trust
the "B" argument I'd passed to 'cpio' 9 years ago on my Irix desktop, I tried the 'dd' command which
had worked to read the first block off the 'tar' tape:

[localhost]# dd if=/dev/st0 of=testfile ibs=256k count=1
0+1 records in
10+0 records out

[localhost]# ls -l testfile
-rw-r--r--    1 root     root         5120 Sep 28 15:11 testfile

Looks like the 256k blocksize was overkill, but doubly gratifying to see 'dd' working as
advertised: it stopped reading at the first IRG.  Cool.

Another check to confirm that my tape's paper label was correct:

[localhost]# file testfile
testfile: ASCII cpio archive (SVR4 with no CRC)

Great!  OK, a little reading of the 'cpio' man page, a couple of trials, and I find this
incantation is the one required to recover archives from that tape:

[localhost] # cpio -ivBc -I /dev/st0

... which makes me especially glad that when I made the archive 9 years ago, I assumed that
I *just might* have to read the tape on a non-Irix system, so I had _made sure_ to *create* the
cpio archives with the "B" blocking option.

I mentioned earlier that I had made backups to 4mm tape using tar, cpio, and bru ("Backup and Recovery
Utility", peculiar to Irix).  What I didn't mention is that each of those was a copy of the same
filesystem.  I wasn't sure which of those tapes I would be able to read years down the line (now!)
and which I wouldn't be able to read.  Turns out that 'tar' and 'cpio' were the big winners, and 'bru'
was the loser.  So, I still had duplicate and complete copies of my old filesystem.  Belt and
suspenders approach sometimes pays off, folks.

It's interesting to note that I had found a couple of *unlabled* 4mm tapes which I couldn't
tell were blank or not.  Using 'dd' and 'file' as above, I was shocked to find that although one
was blank, the other actually had a 'tar' archive!  Reading out the contents, I determined that
it was actually a test tape, which I'd apparently made at some point in preparation for backup,
and hence no there was no data worth recovering, but it was still gratifying to see that a bit of
detective work is always worth the extra effort.

For the sake of completeness, I should mention that the issue of byteswapping never
came up.  I tested for it, but it turns out not to have been a factor.

I hope someone else in a similar predicament finds this account useful.

Russell Whitaker


>Date: Tue, 16 Sep 2003 16:48:13 -0700
>To: redhat-list redhat com
>From: Russell Whitaker <whitaker best com>
>Subject: Reading Irix DAT tapes under RH9
>
>
>-- 
> 
>Hello,
>
>I have a number of tapes I wrote - and verified - a few years ago on various SGI (Silicon Graphics) workstations running Irix 5.2 and Irix 6.2.  The tapes are Maxell HS-4/60s 2GB DAT tapes.  I  have a Red Hat 9 workstation in which I installed an old Python DAT drive, which seems to have installed perfectly (output of dmesg):
>
>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
>        <Adaptec 2930CU SCSI adapter>
>        aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
>
>blk: queue c365cc14, I/O limit 4095Mb (mask 0xffffffff)
>  Vendor: ARCHIVE   Model: Python 27871-XXX  Rev: 1214
>  Type:   Sequential-Access                  ANSI SCSI revision: 02
>blk: queue c365ce14, I/O limit 4095Mb (mask 0xffffffff)
>
>Version of kernel:
>
># uname -r
>2.4.20-8
>
>Tape status:
>
># mt -f /dev/st0 status
>SCSI 2 tape drive:
>File number=0, block number=0, partition=0.
>Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)).
>Soft error count since last status=0
>General status bits on (45010000):
> BOT WR_PROT ONLINE IM_REP_EN
>
>Several of the tapes were written with cpio (using "cpio -ovBc -O /dev/tape" under Irix), and some were written using tar and Backup (a wrapper to 'bru').  I can't read any of these tapes; I can't even use 'dd' to attempt to dump the tape contents:
>
>[root localhost tape1]# dd if=/dev/st0 of=archive1
>dd: reading `/dev/st0': Input/output error
>0+0 records in
>0+0 records out
>
>Do I need to set another blocksize?  Do I need to swap bytes?  I've been Googling for hours on this problem to no avail.  Anyone dealt with this before?  I can't tell the blocksize of the tapes: there doesn't seem to exist the "blksize" option ('mt -f /dev/st0 blksize') in Red Hat's 'mt'.
>
>I'm pretty sure that the Python drive works well and the tapes are OK: I sacrificed the data on a couple of tapes , successfully reading and writing from them; tar, cpio, and dd all worked as they should.?
>
>So, I'm sure the answer lies somewhere in the world of blocksizes and byte orders.  Can anyone help?
>
>Thanks in advance,
>Russell
>


-- 
Russell Whitaker
http://www.survivalarts.com/