SUMMARY: can't read Ultrix 8mm tapes on SUN

From: Loki Jorgenson (loki@nazgul.physics.mcgill.ca)
Date: Tue Jul 30 1991 - 18:21:06 CDT


        SUMMARY: Indeterminate problem reading 8mm tapes on a SUN 3/50
        running SUN OSv3.5.

        My apologies to everyone who tried to answer me; my posting was
poorly phrased. I have no excuses. I endeavour to do better in the future.

        The original problem was that any time that I or another user tried to
read data created in tar or dump format on an 8mm tape from an Ultrix machine,
we would observe what appeared to be "hardware related errors". For
example, "I/O error" or

st0: failed cmd = 8 1 0 0 a 0
st0 error: sense key(0x0): no sense
        sense = f0 0 20 0 0 0 a 12 0 0 0 0 0 0 0 0

Note: No trouble is experienced reading back the SUN tapes on the SUN
or the Ultrix tapes on a DECstation.

        No variation of dd, tar or restore would produce anything else.
I tried to ask in the posting whether there was any well-known reason why
a SUN should not be able to read a DECstation's tape. Just in case I was
chasing faeries. However, I managed only to be terribly obscure.
Many in this list however rose to the challenge and came up with some
credible "intelligent guesses". Thanks to

yih%atom@cs.utah.edu (Benny Yih)
tony@cosc.canterbury.ac.nz
jayl@bit.UUCP (Jay Lessert)
deltam!tigger!jt@uunet.UU.NET (jim wills)
aardvark@marvin.prime.com (Don Koch)
earl@division.cs.columbia.edu (Earl Smith)
scs@lokkur.dexter.mi.us (Steve Simmons)
Aydin Edguer <edguer@alpha.ces.cwru.edu>
rackow@antares.mcs.anl.gov
hall@bond.crim.ca (Ron Hall)
matt@wbst845e.xerox.com (Matt Goheen)
stern@sunne.East.Sun.COM (Hal Stern - Consultant)
phil@dgbt.doc.ca (Phil Blanchfield)
etnibsd!vsh@uunet.UU.NET (Steve Harris)
Mike Raffety <oconnor!miker@oddjob.uchicago.edu>
deltam!flyer!mark@uunet.UU.NET (mark galbraith)
rsk@gynko.circ.upenn.edu (Rich Kulawiec)
phil@dgbt.doc.ca (Phil Blanchfield)

        The answer in our case turned out to be that the native driver
being used on the SUN was using variable record length format while the
DEC machine was using fixed (or is it the other way around?). This has
been confirmed on another machine with a driver which can read both. The
simplest fix seems to be to get (buy) a more flexible driver from a company
like Delta Microsystems or do some hardware level DIP-switching on the
8mm drive (I don't know how to do that yet but see the suggestions below)
to make it read either variable or fixed records as needed.

        The other major potential problem is byte and/or quad swapping.
This problem manifests itself in the form of readable tapes (at least
dd can read them) which yield nonsense. Altenately, one can experience
similar problems with incorrect blocking factors. This was not our case.

        Below are the various suggestions that I received. They make a
fine list of potential problems to be watched for on 8mm drives. I hope
it helps someone out there.

Thanks to all,
                               _ _ _ _
Loki Jorgenson \ O\/O / node: loki@Physics.McGill.CA
Grad/Systems Manager \_/\_/ BITNET: PY29@MCGILLA
Physics, McGill University / \/ \ fax: (514) 398-3733
Montreal Quebec CANADA _/ _/\_ \_ phone: (514) 398-7027

                      -* Chemically balanced *-

        ========================================================

From: tony@cosc.canterbury.ac.nz

We used to do dumps from a Vax to an exabyte tape, and we could read these tapes
on a Sun-3. Dump was clever enough to do byte swapping _and_ quad swapping.
So maybe you have to do both. Another difference between BSD and SunOS dumps
was that the Sun blocksize was twice the BSD dump blocksize (1024 v's 512
bytes), and dump certainly barfs if you give it the wrong blocking factor.

It shouldn't be too hard to write a filter to do the appropriate swapping
from "dd". On the other hand, if dd'ing from the tape gives you an I/O
error, you might as well give up...

        ========================================================

From: jayl@bit.UUCP (Jay Lessert)

Hmmm, I suspect you're right about the the byte swapping. For instance,
with a 10KB block size, the following *ought* to work:

    dd if=/dev/rstX bs=10k conv=swab | tar tbf 20 -

Jay Lessert {decwrl,cse.ogi.edu,sun,verdix}!bit!jayl

        ========================================================

From: deltam!tigger!jt@uunet.UU.NET (jim wills)

On the Mx-Card there are 8 DIP switches (at least the newer ones do) . Try fliping the J3 switch on. J3 in the on position will cause the evenbyte to get disconnected.

Since you were suppecting a byte swapping problem, this maybe the solution.

Jim Wills, Systems Administrator
Delta Microsystems, Inc. Voice (415) 449-6881
111-C Lindbergh Ave. Fax (415) 449-6885
Livermore, Ca. 94550 Email jwills@deltam.com

        ========================================================

From: aardvark@marvin.prime.com (Don Koch)
 
I wouldn't bet on a Sun running SunOS 3.5 to be able to read an Exabyte
tape from a strange machine (have you even tried reading its own tar tapes?).
We had a similar problem reading a tar tape from outside, although our
EXL 7000 read it just fine. (Rumor has it that Sun improved the Exabyte
support at 4.1.)

For the byte swap problem, you might try:
  dd if=/dev/mt8 of=output_file.tar conv=swab

where /dev/mt8 is replaced with the actual drive device. You should
be able to "tar -tvf" the output_file.tar or at least "od" it (octal dump)
to see if it makes any sense at all.

        ========================================================

From: earl@division.cs.columbia.edu (Earl Smith)

I had two problems. The second was covered in the past two weeks in
sun-managers.
1. The device driver might not handle the tape the same way. In particular
    I had a tape written by the Sun-supplied device driver with 4.1.1 (a dump
    backup) written on my Sun 4/490 and couldn't read it on my Sun 4/390.
    It turned out that the 4/390 was using the Delta Data device driver, and
    that I had to read it with variable length blocks set in order to read it.
    I would have thought the Delta driver would have at least read tapes
    written by the Sun driver, but no such luck. I spent a week or so on
    that problem. So life goes.
2. Another problem that just started turning up with people's new batches of
    tapes is that tapes gave errors the first time they were written. IF they
    were then rewound and re-written they worked fine. But if they took a new
    tape out of the package and rewound it and tried to write it, they got an
    error. At first I thought it was the clock in the tape drive (there is a
    clock that tells the tape drive when the tape should be up to speed after
    it starts turning it). It turned out that the VCR industry had been having
    some problems, and because of that they changed the standard for 8mm tapes.
    People using VCRs noticed fewer problems. Those using the tapes on
    computers started getting these errors. It required a revision in the
    tape controller chip set to fix it. Check sun-managers. I didn't get
    this one myself, probably because I'm still using old tapes, but I spoke
    with people who did.

earl smith
earl@cs.columbia.edu

        ========================================================

From: scs@lokkur.dexter.mi.us (Steve Simmons)

I can make an intelligent guess....

Between 3.5 and 4.X, the Sun scsi tape interface changed pretty
radically. If you used the Sun driver, the tapes would barely
interchange. Tape marks in particular were odd. It would not
surprise me to see that 4.1 and Ultrix had similar incompatibilities.

In a few weeks we'll be finding out for ourselves -- 8mm drives
coming for our Ultrix boxes.

        ========================================================

From: Aydin Edguer <edguer@alpha.ces.cwru.edu>

Not that I know of. I was able to read a tape produced under Ultrix 3.1
under SunOS 4.1 so I know it can be done using dump/restore at the very least.
Possible reasons for problems would be variable block mode versus fixed
block mode being used on the tape drives.

        ========================================================

From: rackow@antares.mcs.anl.gov

The problem is more along the lines of blocking factors. The exabyte has 4
(I think) modes of writting tapes. They are {512,1024}{fixed,variable}end
byte block formats. Sun uses oneof those formats while dec uses a different
one. If you want to go back and forth between the machines on Exabyte, I
recommend you contact Delta Micro Systems. Their device driver will allow
you to read/write all the different formats.

Another thing to watch out for is that as the drives age, they may drift
in how they are writting the tape. The drive may be out of alignment
and be causing some of your problem, but the format is probably the biggie.

   Gene Rackow email: rackow@mcs.anl.gov
   Math & Computer Science voice: 708-972-7126
   Argonne National Lab FAX: 708-972-5986
   9700 S. Cass Ave. / Argonne, IL 60439

        ========================================================

From: hall@bond.crim.ca (Ron Hall)

        You did not mention what type of format you wrote out in I am
        assuming it is a dump tape. yes? Well if it is a dump tape then
        you are in for a suprise...you may not be able to read it at
        all! Seems that there are two ways to write data on exabyte
        tapes most everyone does it one way and some do it other ways.
        The exact details I forget, but it is more complicated than byte
        swapping (If my memory serves me???). We had this nasty suprise
        when we tried to restore a tape written on a Solbourne on to a
        Sun 4/280 boy was I irked. If you really want to try dd and you
        really suspect that it is a byte ordering problem try the
        following. I will assume that the input device (read exabyte) is
        /dev/rst1:

        dd if=/dev/rst1 bs=20 conv=swab | restore -ivf -

        if it is a tar tape (which is supposed to be vendor idependent)

        dd if=/dev/rst1 bs=20 conv=swab | tar tvf -

        [Also we had] this [variable record length] problem.
        I had forgotten the actual details. WIth us it has been
        the variable format is used on one of our drive and the fixed
        on all the others.

        ========================================================

From: matt@wbst845e.xerox.com (Matt Goheen)

I would bet it's the old variable/fixed record size problem. However, I
don't know how to get Sun's standard driver to switch between the two.
Delta Microsystems has (sells) a driver that allows you to access the
drive either way. Perhaps someone else can give full details...

        - Matt Goheen

P.S. Then again, it could be byte swapping. But that wouldn't make
     it so you couldn't read the tape -- you just would be able to
     decipher it. You fail to mention exactly what error you are getting.

        ========================================================

From: stern@sunne.East.Sun.COM (Hal Stern - Consultant)

are you sure the tape is completely rewound and retensioned?
one drive may not have left the tape snug and the other
may not retension it. try
                mt -f /dev/rst1 retension
before you use tar/dd etc

        ========================================================

From: phil@dgbt.doc.ca (Phil Blanchfield)

This is strange, I have Exabyte tapes on both a sparc-2 (4.1.1) and a
VAX-750/ULTRIX (3.1) system. No problem with either tar or dump tapes.
just stick 'em in and type the tar or dump/restore command. As I understand
it the MIPS boxes have the same byte ordering as the VAX boxes.

We did have a byte swaping problem with a Silicon Graphics WS and SUN though.
The magic dd command was:

(putting files onto the SGI from a tape written to on a SUN)

dd if=<tape-device> conv=swab bs=20k | tar xf -

The problem might somehow have something to do with the drives. If it's
possible I would disconnect the Exabyte drive from the ULTRIX box and
plug it into the SUN and then just use regular dump/restore/tar commands.

-- 
Phil Blanchfield
The Communications Research Centre 3701 Carling Avenue, Ottawa Ontario CANADA
Internet: phil@dgbt.doc.ca	OR	phil@dgbt.crc.dnd.ca

Reply-To: wuthel!brand@lll-winken.llnl.gov

If it is really a byte order problem the phrase "conv=swab" is what you want

========================================================

From: etnibsd!vsh@uunet.UU.NET (Steve Harris)

Are you totally unable to read the tape? What happens when you do:

dd if=$TAPE of=/dev/null bs=16k

I assume you are getting read errors (otherwise, it is just a matter of transforming the data, which you should be able to figure out).

If you get read errors, try putting the other Exabyte on the Sun. (hypothesis: the two Exabytes are out of alignment with respect to each other, whatever that means).

If that still doesn't work, it would seem that somehow the uVax is writing with some different format. Perhaps with some funny block size. We got our Exabyte from Delta Micro, who also provided a custom driver -- they seem to know a lot about these beasts, about blocking, etc., perhaps you should talk to them? (they may respond directly to your query anyway).

Good luck,

Steve Harris - Eaton Corp. - Beverly, MA - uunet!etnibsd!vsh

========================================================

From: Mike Raffety <oconnor!miker@oddjob.uchicago.edu>

If you're using SunOS 3.5, then you're presumably using a third-party software driver. For the Delta Microsystems software, there are THREE formats to read/write Exbyate tapes in ... from the smt(4) man page:

DESCRIPTION Files with minor device numbers 0 through 3 refer to the first three drives. Adding 4 to the minor device number addresses the drives in a non-rewinding mode. Adding 8 to the minor device number addresses the drives in a 512 byte fixed block mode. Adding 16 to the minor device number addresses the drives in a variable record size mode.

Farther down, it also says:

The /dev/rmst0 and /dev/nrmst0 use 1024 byte fixed block transfers. The number of bytes in any given transfer must be a multiple of 1024. If it is not, the device driver returns an error. This mode uses the tape media most effec- tively

The /dev/srmst0 and /dev/nsrmst0 use 512 byte fixed block transfers. The number of bytes in any given transfer must be a multiple of 512. If it is not, the device driver returns an error. The tape capacity is reduced by a factor of two in this mode.

The /dev/vrmst0 and /dev/nvrmst0 use variable length record transfers. The size of a transfer can be from 1 to 63484 bytes. When reading a record, the number of bytes actually read is returned. If the number of bytes requested is less than the record size then only the number of bytes requested are transfered and the rest of the bytes are skipped. That is to say the next read will start with the next record, not with the first of the unread bytes. Tape usage can be estimated by rounding the record length up to the next 1024 byte boundary. If a 1536 byte record is used, the tape capacity is reduced by aproximately one fourth.

So, try all three devices before giving up. FYI, the SunOS 4.x st driver uses either srsmt or vrsmt format, not a simple rsmt. (There seems to be a series of typos in the man page; read smt for mst above.)

Please be sure to summarize back to the list.

========================================================

From: deltam!flyer!mark@uunet.UU.NET (mark galbraith)

There are several modes that an Exabyte drive might be configured in. The standard mode for Exabytes is to use a 1024-byte block on the tape. Sun on the other had overrides this so that it writes variable-length blocks on the tape. Without modifying the hardware setup (a couple of DIP switches) , or installing a third party driver (like ours), you probably won't be able to interchange data between these two drives.

I know this might be a little late getting to you, but I was out sick yesterday. Sorry for the delay. Contact me directly if you need more information.

--Mark Galbraith Voice: +1 415 449 6881-- --Software Engineer UUCP: uunet!deltam!mark-- --System Administrator/Postmaster Domain: mark@deltam.com-- --Delta Microsystems, Inc. Compuserve: 76234,3126--

========================================================

From: rsk@gynko.circ.upenn.edu (Rich Kulawiec)

If dd can't read your tape, you might be out of luck, since dd makes no attempt to interpret the bytes that it reads. But it's possible that you're using the wrong blocking factor, so what I'd recommend trying is:

tcopy /dev/rst8 (or whatever your Exabyte drive is)

tcopy with one argument just catalogs the tape; it should tell you how many (physical) files are on there, the blocking factor, etc., and that should tell you whether or not there's any data on the tape.

========================================================

From: phil@dgbt.doc.ca (Phil Blanchfield)

I mailed you before about this and said that I had no problems reading ULTRIX dump tapes on a SUN. I just noticed the following message when I "restore -i" an ULTRIX tape on a SUN 4.1.1 system:

vega% restore -if /dev/nrst0 Note: Doing Quad swapping <<<<<< restore >

First of all I find it strange that your SUN-OS does not do this, perhaps you have an older version.

Second dd's swab will not fix this it only switches bytes.

eg. On the tape is "AABBCCDD" what SUN-OS dump wants to see is "DDCCBBAA" dd`s swab would turn it into "BBAADDCC".

You might try hacking out a simple 'C' program to do the "Quad swappling" and use something like "dd if=tape bs=20k | qswap |restore -if -".

Good Luck!

-- Phil Blanchfield The Communications Research Centre 3701 Carling Avenue, Ottawa Ontario CANADA Internet: phil@dgbt.doc.ca OR phil@dgbt.crc.dnd.ca

_ _ _ _ Loki Jorgenson \ O\/O / node: loki@Physics.McGill.CA Grad/Systems Manager \_/\_/ BITNET: PY29@MCGILLA Physics, McGill University / \/ \ fax: (514) 398-3733 Montreal Quebec CANADA _/ _/\_ \_ phone: (514) 398-7027

-* Chemically balanced *-



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT