Hi Chris, Have you looked at: http://www.comet.ucar.edu/resources/cases/casedoc.htm#Tape_Procedures Comments embedded below.. -Jeff ____________________________ _____________________ Jeff Weber address@hidden Unidata Support PH:303-497-8676 NWS-COMET Case Study Library FX:303-497-8690 University Corp for Atmospheric Research 3300 Mitchell Ln http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000 ________________________________________ ______________________ On Wed, 3 Apr 2002, Unidata Support wrote: > > ------- Forwarded Message > > >To: address@hidden > >cc: Chris Herbster <address@hidden>, > >cc: Mike Masscotte <address@hidden> > >From: Chris Herbster <address@hidden> > >Subject: reading case study tapes? > >Organization: Embry-Riddle University > >Keywords: 200204031507.g33F7ja07422 COMET casestudies > > Hi all, > > We have been unable to read the tapes for the case studies and I think > we have determined the problem. (We do know that the tape drive > appears to be working okay.) > > We think that there is a mis-match between the block size used to make > the tapes (assuming a Sun Unix system) and our Linux systems here. Can > you provide any info on what blocking factor I should use to read these > tapes? Also, since we specified "compressed" format, is this done with > hardware/firmware or do I also need to use the "z" option in GNU tar? > Finally, should I be using one of the other devices besides /dev/st0 > (for compression)? > No compression on the tapes, just high density vs low density.. <from man tar> b Blocking Factor. Use when reading or writing to raw magnetic archives (see f below). The block argument specifies the number of 512-byte tape blocks to be included in each read or write operation performed on the tarfile. The minimum is 1, the default is 20. The maximum value is a function of the amount of memory available and the blocking requirements of the specific tape device involved (see mtio(7I) for details.) When a tape archive is being read, its actual blocking factor will be automatically detected, provided that it is less than or equal to the nominal blocking factor (the value of the block argument, or the default value if the b modifier is not specified). If the actual blocking factor is greater than the nominal blocking factor, a read error will result. <end> Do we see this read error? > address@hidden ~]$ ll /dev/*st0* > crw-rw-rw- 1 root root 9, 128 Mar 30 22:20 /dev/nst0 > crw-rw-rw- 1 root root 9, 224 Mar 30 22:20 /dev/nst0a > crw-rw-rw- 1 root root 9, 160 Mar 30 22:20 /dev/nst0l > crw-rw-rw- 1 root root 9, 192 Mar 30 22:20 /dev/nst0m > crw-rw-rw- 1 root root 9, 0 Mar 30 22:20 /dev/st0 > crw-rw-rw- 1 root root 9, 96 Mar 30 22:20 /dev/st0a > crw-rw-rw- 1 root root 9, 32 Mar 30 22:20 /dev/st0l > crw-rw-rw- 1 root root 9, 64 Mar 30 22:20 /dev/st0m > > I'm trying to determine what each of the device nodes does. The only > ones that give a non-error to mt are the base nodes. > > address@hidden ~]$ mt -f /dev/nst0 status > SCSI 2 tape drive: > File number=0, block number=0, partition=0. > Tape block size 1024 bytes. Density code 0x15 (EXB-8500 or QIC-1000). > Soft error count since last status=0 > General status bits on (45010000): > BOT WR_PROT ONLINE IM_REP_EN > > address@hidden ~]$ mt -f /dev/nst0a status > /dev/nst0a: No such device or address > > address@hidden ~]$ mt -f /dev/nst0l status > /dev/nst0l: No such device or address > > address@hidden ~]$ mt -f /dev/nst0m status > /dev/nst0m: No such device or address > None of these will work as the systen cannot "see" these devices.. We simply run tar xvf /dev/rmt/?bn (do this until no more tar files) Where ? is the device # (0 or 1 in our case) b indicates binary data, and n is for no rewind. Probably not much help, but maybe some light got shed on something with the URL and comments, keep me posted and I am digging deeper as well. Thanks, Jeff Unidata Support > We're running Redhat 7.1 on this system. > > Thanks!!! > > Chris H. > > > Dr. Christopher G. Herbster > Assistant Professor > Applied Aviation Sciences > Embry-Riddle Aeronautical Univ. > 600 S. Clyde Morris Blvd. > Daytona Beach, FL 32114-3900 > > 386.226.6444 voice > 386.226.7739 fax > 386.226.6446 Wx. Center > http://opwx.db.erau.edu/ > > address@hidden > > > > ------- End of Forwarded Message > >
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.