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
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
> 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:
Kevin W. Thomas
Sydney S. Weinstein
I am sorry if I've missed anyone. Thanks to all!
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:
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:
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