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. [EMAIL PROTECTED] 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: [EMAIL PROTECTED] >From: Russell Whitaker <[EMAIL PROTECTED]> >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: > >[EMAIL PROTECTED] 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/ -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
