[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20020403: reading case study tapes?

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?

> [herbster@thermal ~]$ 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.
> 
> [herbster@thermal ~]$ 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



> 
> [herbster@thermal ~]$ mt -f /dev/nst0a status
> /dev/nst0a: No such device or address
> 
> [herbster@thermal ~]$ mt -f /dev/nst0l status
> /dev/nst0l: No such device or address
> 
> [herbster@thermal ~]$ 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
> 
>