Vous êtes sur la page 1sur 5

Reading Irix DAT tapes under RH9

From: Russell Whitaker <whitaker best com>


To: redhat-list redhat com
Subject: Re: Reading Irix DAT tapes under RH9
Date: Sun Sep 28 18:35:03 2003

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.
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:

First,

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!
512bytes".

The argument "-b 512" means "using a blocksize of 512 x

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
>

Vous aimerez peut-être aussi