Re: 20020403: reading case study tapes?
Have you looked at:
Comments embedded below..
Jeff Weber jweber@xxxxxxxx
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: support@xxxxxxxxxxxxxxxx
> >cc: Chris Herbster <herbstec@xxxxxxxx>,
> >cc: Mike Masscotte <masscotte@xxxxxxxxxx>
> >From: Chris Herbster <HerbsteC@xxxxxxxx>
> >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.
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.
> We're running Redhat 7.1 on this system.
> 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
> ------- End of Forwarded Message