SUMMARY: Exabyte 8500 drive compression mode?

From: Roger H. Kou (rkou@hto.usc.edu)
Date: Tue May 03 1994 - 00:22:41 CDT


Good morning,

My original question is as follows:

> From man st on our SunOS 4.1.3 server, a 4/670MP, there is an indication
> that we can write stuff in compression mode with our Sun Extabyte drives.

> The man page says nrst[16-23] are to be used for compression mode.
> But we can't make it work!

> Has anyone done this before? How?

Let me restate what I said:

        1) we have two Sun 8mm (aka Exabyte) drives
           mt -f /dev/nrst8 and /dev/nrst9 show them as EXABYTE-8500

        2) SCSI IDs are 4 and 5 respectively on those drives.

        3) They are connected to a Sun 4/670MP running 4.1.3

        4) We don't use any third-party backup software/program
           We use /usr/etc/dump and rdump

        5) It does everything, except the compression(which we believed
           they're capable of doing, hence the question I posted to you)

        6) We have tried just about everything. And the only way we
           were sure is this:

                  DUMP: Tape write error 1811 feet into tape 1
                  DUMP: NEEDS ATTENTION: Do you want to restart?:

           that we ran out of tape and we've written about 5G when
           that happens. So we want to use compression for more capacity.

Almost everyone said "no, Sun's 8500s don't do compression. You need a
third-party Exabyte drive model 8500c, 8505."

Undaunted, I talked to my local tech person and informed him that I
was going to call up Sun service USA, (800)872-4786, to ask them what
our drives can do and can't do. Amazingly, after registering my first
call with them, a tech called me back right away. I must said they're
*much* more responsive than our local computing service center. But
that's another story. And the local Sun person in charge of the
service contract was very responsive also. She called me backed and
informed me that I can go ahead call the Sun services since she has
our service contract. However, what the tech told me was less helpful
than I expected. Or maybe I just have a too high of an expectation. We
want the compression because we thought we can put more on a tape than
w/o the compression (common sense, right?). That is, we can put 5G on
a tape with our 8500s, but we thought we can put maybe 10G on a tape
with compression. No no no no no, said the Sun tech, just think, he
said, if that's possible, wouldn't we tell you that in the first
place? He goes on and read me the 4.1.2 man page about a bug in the
man page(?) that says something to the effect of that.

Anyhow, the Sun tech said that 8500 does compression(say what?), but
you can only get 5G max, one way or another. So we just left at that
since his earlier argument for why we can't write more than 5G on a
tape is stronger than his technical explanation. He went on explaining
that most calls about Sun's Exabyte drive are about the 2.2 and 5G
difference; i.e., high and low density. Of which we have no problem
of doing.

I want to thank everyone who responded(especially Cecil Pang for her
detail 8500 doc, which I've included at the end of this summary), and
I hope this is helpful. Here are some of the helpful information I got:

> You can learn a bit more about this by looking at
> /sys/scsi/targets/st_conf.c. Take a look the density codes.

> If you have an 8500C, then you need to add an entry for it to the
> st_conf.c file and recompile.

> You'll also have to modify your kernel so that it knows what is 8505
> is.

> the SUNOS options don't actually do compression, they just
> know how to talk to a controller that has the compression option...

> If you buy from 3rd party a EXB-8500C or even better a EXB-8505 you have
> compression mode after some kernel work.

                        8200 8205 8500 8500C 8505
  2.3 gb mode yes yes yes yes yes
  2.3 gb w.com. mode - yes - - yes
  5.0 gb mode - - yes yes yes
  5.0 gb w.com. mode - - - yes yes

> Remember once you write stuff using lo-density on the tape you need to
> bulk erase it before you can change it to hi-density mode reliably.
> i.e. Use a magnatic eraser.

> If you are using Solaris, to get the higher density you need to
> specify the density,(I just found this out although I haven't tested
> it to make sure). So if you have a device that's at say, target 0, for
> the 2.3GB density you would specify /dev/rmt/0l or for 5.0GB density
> /dev/rmt/0m. The 'l' and 'm' specify low or medium.

Thanks to the following people:
Michael Baumann
Louis Brune
Chuck Campbell
Chuck Foley
Steve Letter
Dan Lorenzini
Joe Mervini
James Mularadelis
Martin Oksnevad
Cecil Pang
Garry Perratt
Bob Reardon
Tami Shoham
Michael Sullivan
Kevin W. Thomas
Han Tunca
Sydney S. Weinstein

I am sorry if I've missed anyone. Thanks to all!

-RK

SYNOPSIS : dump commands for 8mm tape drives

DETAIL DESCRIPTION : The documentation is not clear on what dump options
                     should be used when dumping to an 8mm tape.

                     When the correct options are not used, the result may
                     be write errors. Another symptom can be that not all
                     of the tape is being used by dump.

SOLUTION SUMMARY :

NOTE: See the man pages for dump or ufsdump for additional
      options. The below examples show the minimum options
      to obtain a full level 0 dump.

1) If the system is running SunOS 4.x:

   For a 5gb tape drive use the following:

     # dump 0bdsf 126 54000 13000 /dev/<tape> /dev/<partition>

   For a 2.3 Gb tape drive (120-minute video) use the following:

     # dump 0bdsf 126 54000 6000 /dev/<tape> /dev/<partition>

   For a 2.3 Gb tape drive (90-minute video) use the following:

     # dump 0bdsf 56 4100000 5190 /dev/<tape> /dev/<partition>

 For <partition> specify the partition to be backed up using
 the format: sd0a, id001g, etc.

 <tape> is assigned as follows:
 _____________________________________________________
                Low-Density High-Density
 Tape Unit (8200) (8500)
 _____________________________________________________
   st0 /dev/rst0 /dev/rst8
   st1 /dev/rst1 /dev/rst9
   st2 /dev/rst2 /dev/rst10
   st3 /dev/rst3 /dev/rst11
   st4 /dev/rst4 /dev/rst12
   st5 /dev/rst5 /dev/rst13
   st6 /dev/rst6 /dev/rst14
   st7 /dev/rst7 /dev/rst15
 _____________________________________________________

2) If the system is running SunOS 5.x (Solaris 2.x):

 Use the following command for all tape drives:

  # ufsdump 0bf 126 /dev/rmt/<tape> /dev/rdsk/<partition>

 ufsdump is able to detect end of media properly, therefore
 there is no need to specify the size option. Also, the
 default density is 54000, so there is no need to specify
 this in the command.

 For <partition> specify the partition to be dumped in
 the format: /dev/dsk/c0t3d0s0

 <tape> is assigned as follows:

 _____________________________________________________
                Low-Density High-Density
 Tape Unit (8200) (8500)
 _____________________________________________________

    0 /dev/rmt/0l /dev/rmt/0
    1 /dev/rmt/1l /dev/rmt/1
    2 /dev/rmt/2l /dev/rmt/2
    3 /dev/rmt/3l /dev/rmt/3
    4 /dev/rmt/4l /dev/rmt/4
    5 /dev/rmt/5l /dev/rmt/5
    6 /dev/rmt/6l /dev/rmt/6
    7 /dev/rmt/7l /dev/rmt/7

KEYWORDS : dump, 8mm, exabyte

PRODUCT : dump_restore

SUNOS RELEASE : all

UNBUNDLED RELEASE : n/a

HARDWARE RELEASE : all

ISO-9001 STATUS : Controlled



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:00 CDT