Very Computer

Does anyone know how to teach Slackware (kernel 1.0.19 with NCR boot disks)
the details of using an Archive Python 4mm SCSI-2 tape drive?

I can write tapes with Linux and read them back. I can also read such a tape
on a Sun SparcStation (Solaris 2.3) at the office. But I cannot write a tape
on the Sun and read it in Linux: I get an immediate I/O error,  and
"mt -f /dev/st0 status" results in "unknown device type (114)".

My current theory is that Solaris knows exactly how to control an Archive
Python drive (the documentation speaks explicitly about this drive), and
uses something which the generic SCSI tape support in Linux does not
understand. Does that sound reasonable?

Any other ideas to try out?

Quote:>Any other ideas to try out?

--- mt.c~       Sat Aug  7 15:50:44 1993

 #endif
 #ifdef linux
        { MT_ISSCSI1,   "SCSI 1",       0,              0 },
+       { MT_ISSCSI2,   "SCSI 2",       0,              0 },
 #endif
        { 0 }
 };

Regards,

Wolfram.

: Does anyone know how to teach Slackware (kernel 1.0.19 with NCR boot disks)
: the details of using an Archive Python 4mm SCSI-2 tape drive?

: I can write tapes with Linux and read them back. I can also read such a tape
: on a Sun SparcStation (Solaris 2.3) at the office. But I cannot write a tape
: on the Sun and read it in Linux: I get an immediate I/O error,  and
: "mt -f /dev/st0 status" results in "unknown device type (114)".

I have an Archive Python at home and also have access to a Sparcstation
at work running plain old SunOS 4.1. I ran into the same problem. I solved
it by tarr'ing the stuff I want on disk first and then using the dd command
to put it on the tape. I was able to retrieve it with dd on my linux box.

One thing I've been meaning to try is if I used dd to put the tar file
on tape using the SunOS box, can linux tar read the tape directly without
having to use dd to put it on disk first.

Shawn.

: My current theory is that Solaris knows exactly how to control an Archive
: Python drive (the documentation speaks explicitly about this drive), and
: uses something which the generic SCSI tape support in Linux does not
: understand. Does that sound reasonable?

: Any other ideas to try out?

--
           /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\  
          / /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \  
         / /                  M. Shawn Easter                    \ \

     /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
    |                   Get lean, mean, and strong.                    |
    +------------------------------------------------------------------+

In 3 out of 4 cases I have heard of so far the  problem  was  Solaris
using  a  larger  buffer  size than the default settings in the Linux
tape   driver   can    handle.    Changing    the    definition    in
/usr/src/linux/drivers/scsi/st.c  to  "#define  ST_BUFFER_BLOCKS 128"
(giving Linux an 128 kB I/O  buffer  for  tape)  and  rebuilding  the
kernel  fixed  the problem. In the 4th case I did not receive a reply
yet...

Maybe this should become a FAQ.

Wolfgang

If it's working, the diagnostics say it's fine. If it's not  working,
the diagnostics  say  it's  fine.
- A proposed addition to rules for realtime programming

| The is no "different low-level formats" that different systems  could
| use. Everything is pretty standardized. Well, mostly everything :-(

Tape block sizes are about as close as you get to "low level format" I
would think. You're right, but he had the right idea.

| In 3 out of 4 cases I have heard of so far the  problem  was  Solaris
| using  a  larger  buffer  size than the default settings in the Linux
| tape   driver   can    handle.

An interesting test would be to write the tape on the Sun with dd and an
obs=64k clause. That *may* cause writes in smaller blocks if you do it
to the raw device.

I would expect Sun tar to use 10k or 20k block size, though, and Linux
should handle that.
--
Speaking *from* but never *for* Prodigy
        "Pain builds m*fiber"  -my dad
        "Pain hurts"  -me

Thanks for all the helpful replies to my original message!

The final solution was surprisingly simple:

Issue the command 'mt -f /dev/st0 setblk 0' and Linux suddenly can
handle all tape blocking formats (up to its buffer capacity) which the
Sun can create. The "mt ... setblk 0" sets the tape drive to "variable
blocking" - and that's the whole secret.

Without the "mt" command, tapes are only interchangeable between
Linux and Solaris 2.3 if the blocking factor is specified as "1", as in
"tar -cvb 1 -f /dev/rmt/1l" on the Sun.

Again, thanks a lot for all the help!

   Thanks for all the helpful replies to my original message!

   The final solution was surprisingly simple:

   Issue the command 'mt -f /dev/st0 setblk 0' and Linux suddenly can
   handle all tape blocking formats (up to its buffer capacity) which the
   Sun can create. The "mt ... setblk 0" sets the tape drive to "variable
   blocking" - and that's the whole secret.

Nice to know.

I stopped over this message because I'm interested to know how easy would
it be to exploit the Python's unique(?) ability to read Audio DAT tapes?
It's done regularly under SGI IRIX.

Cheers,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) | "Of course Australia was marked for
                                       |  glory, for its people had been chosen

                                       |                         -- Anonymous