Very Computer

We upgraded from Solaris 2.3 to 2.4.  I never saw any notice that the
st driver was changing.  Be that as it may, it did change.  The st
driver now queries the drive to see how big a block the device can
write, and then it uses that block size (unless, of course, you've
gone to set the block size yourself).  The consequence is that if
you use C or Fortran (or whatever) to write a tape on 2.4, the block
size may be much larger than before.  Which means if you try to take
that tape to an older system, like 4.1.x, the block size will be too
big for the older system to read.

I've called Sun's hotline several times.  They've got a mind-set:
they keep wondering whether tapes from old systems can be read....

of course they can.  The problem (and it's even pointed out in
the st man page) is that 2.4 tapes won't go to OLDER systems.
Old systems can be read.

Sun's "solution" is to turn the tape drive into a tape drive that
can't write bigger blocks via doctoring st.conf .  That's just not
acceptable.  The Navy (the U.S. Navy -- you've read about them in books
and stuff) has lots and lots of 4.1.x systems; the Navy once picked Sun
workstations as their standard.  Well, we write tapes to send to the
Navy.  So we have to be able to write tapes they can read.  But we can't
play dog in the manger forever -- someday, a 2.4 tape is going to come
into the building and we'll need to read it.

We have a 2000E with eight tape drives.  It's common for all eight to
be in use at once.  So we can't just unload and reload the st driver
when the mood strikes us.  The people who wrote C and Fortran for the
last 20 years didn't put a "set blocksize" option in their programs.
(20 years is a serious statement -- it may be more, but 20 that I know of.)
So just because dd and so on have such options doesn't help me at all.

I ****MUST**** be able to write tapes compatible with older systems.
(Unless you can get the Navy to upgrade.)  I ****CAN'T**** play dog
in the manger forever.  I ****CAN'T**** reboot the system like it was
a toy.  I ****MUST**** have some way to turn the "old system compatibility
mode" on and off without rebooting/unloading & loading the st driver.

You may be in similar waters.  I've already tried lobbying Sun for
a fully-backward compatible tape driver, if you think you're going to
wind up in the same boat, you need to add your voice to mine.

thx.
--
Jay Scott               512-835-3553

Applied Research Labs, Computer Science Div.
University of Texas at Austin

Then you must not have read the "Solaris 2.4 Open Issues & Late Breaking
News" included with Solaris 2.4.  Mine (from the 11/94 release) clearly
describes the problems you're experiencing in the section titled
"Compatibility Problems with Pre-Solaris 2.4 tapes."

--
------------------------------------------------------------------------

Have two versions of your st.conf file.  Let's call them st.conf.variable
and st.conf.fixed.  The first one has a 0 in the third parameter position
of the ``data'' parameter value string.  That will make Solaris 2.4 do
the variable length record schtick.  The other one (st.conf.fixed) will
have whatever fixed block size you need to use for your Navy tapes in
that third parameter position.

Now make yourself two scripts called `set-st-fixed' and `set-st-variable'.
The first one will do an `rm' on the existing /kernel/drv/st.conf file
and will then make /kernel/drv/st.conf a symlink to your st.conf.fixed
file.  It will then do the other commands necessary to unload and then
reload the st driver.

Similarly, your `set-st-variable' command script should `rm' the existing
st.conf file (actually a symlink) and replace it with a symlink to your
st.conf.variable file.  It also will force and unload and then a reload
of the driver.

That ought to do it.  Of course to be really through, you should also
invent some sort of locking protocol (and use it in the scripts) to
make sure that you are only playing these games with the driver when
no tape drives are actually in use.

Obviously, if you have eight different drives on the system, and if
one or more of them are in use most of the time, this is a crappy
solution, but hey!  It is probably better than nothing (which is what
you have now).
--

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------

----------------------------------------------------------------------------

Now I have.  And the solution proposed therein has
been tried, and does not work.

--
Jay Scott               512-835-3553

Applied Research Labs, Computer Science Div.
University of Texas at Austin

Quote:>Obviously, if you have eight different drives on the system, and if
>one or more of them are in use most of the time, this is a crappy
>solution, but hey!  It is probably better than nothing (which is what
>you have now).

But he's right -- I could try this on my little development system.  But
the production environment would  still be broken.

The other problem is:  I've tried the st.conf fix, and it doesn't work.
I don't get behavior which gives me portable tapes.

I'm going to try to re-write the 2.4 st driver.  But, and this is a MAJOR
difficulty, the proposed solution of st.conf hasn't fixed it, so even
using that as my jumping off point for looking at teh st driver may
not get me where I need to go.

I'm still in big trouble....
thanks anyway.
j.
--
Jay Scott               512-835-3553

Applied Research Labs, Computer Science Div.
University of Texas at Austin

I'd be interested in hearing from others for whom this will cause
problems.

I honestly can't imagine any good reason for completely removing any
possibility of doing this (of course, that doesn't mean there aren't
any :-) ). While the tape applications that Sun provides, such as
ufsdump and tar, may not be able to make use of this, there are far
more applications that get raw data off tape which can. A great many
scientific data reduction tasks manage just fine if a couple of records
have to be removed from a large dataset. But they don't work very well
if most of the input data simply can't be gotten at.

What's more, this makes it nearly impossible to copy any quantity of
old tapes to new ones without huge data loss (because you have to
write off the rest of what may be a very large file any time you get
an error). You can't even skip to the next file without the drive
rewinding first, and then only if you're lucky enough that it doesn't
detect the error during the seek. Our need to do this kind of archive
transcription - on over a terabyte of data - has forced us to buy a PC
to read our old 9-tracks (Sun, are you listening?)!!!

At the very least it ought to be selectable by the user. The "no-rewind"
option should really mean just that: don't rewind unless explicitly
instructed to by the user.

Tape handling on most UNIX versions is already pitiful; this doesn't
improve it any.
--
Ruth Milner                            NRAO                  Socorro NM