Thanks to all those who responded to my query. At this point I
have'nt tested the suggestions given, but I shall be doing so in the
next two days. The following are the responses I received.
PS I have the kernel mods (for the SONY SDT-5000S) if interested.
Thanxs again.... Nick
-------------------------------------------------------------------------
From: Stefan Gerberding <stefan@inferenzsysteme.informatik.th-darmstadt.de>
we are using an Exabyte 4mm DAT drive for network backups (using a shell
script to perform selective backups). The drive is unit 1, for /dev/nrst1 we
have compression on and for /dev/nrst9 it is turned off.
(SUNOS 4.1.3 on a SUN SPARCstation10).
-------------------------------------------------------------------------
From: Simon Coppins <coppins@arch.adelaide.edu.au>
> ...can compression be toggled in software...
On the Alphas there are two types of dev entries, the "rmt?h" for
compression and "rmt?l" for use without. Perhaps all you need do is
MAKEDEV the apropro entries. Of course how your driver talks to the
drive is another thing. As far as I can tell the OSF boxes don't know
(in the kernal) that the tape is a compressing DAT etc. all they are
told is that it's SCSI.
> ...density option for rdump was only used to calculate the size of
> the tape and had no bearing on the drive....
Correct. If you use a compressing option you need to use a differnt
density or the dump will screw up the tape size. Also check the
"blocks per write" field for remote dumps. I changed all mine from 10
(10Kb) to 48 and reduced the backup time from 10hrs two about 2.5hrs.
Make this field too big and the dump will fail.
--------------------------------------------------------------------------
From: Chris Wozniak TISC <chris@tisc.edu.au>
> ..."appropriate" minor device number will specify compression...
That's correct. In my case /dev/rst0 is non-compressing drive,
/dev/rst8 is compressing drive, both sending stuff to the same
physical device without need of any intervention.
> ...density option for rdump was only used to calculate the size of
> the tape and had no bearing on the drive....
No - the density is the real parameter. The tape size is spurious,
it has to fool dump about the number of tapes needed for backup.
I'm using the following parameters:
b = block size = 126
s = tape length = 5000
d = tape density = 61000
--------------------------------------------------------------------------
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
> ...can compression be toggled in software...
Not easy. Suns drivers allow you to only select different tape densities
(read st(4s)) through the minor device number bits for 4 different
densities. The values that you can configure for the 4 different densities
are transmitted to the scsi tape device as the density byte of the
density select mode select page. Compression for dat drives is encoded in
a different byte and thus there is no way of toggling this byte short
of a patched driver. For sparccenter 1000 and 2000 and probably other machines
that sun delivers with archive python dat streamer tapes, these streamer
tapes have modified firmware to allow switching of compression through
this density byte, so they work with the - in my opinion - stupid sun
driver.
--------------------------------------------------------------------------
Nick Jeitner PH: +61 8 302 3033
Computer Systems Officer FAX: +61 8 302 3381
School of Computer & Info. Sci. E-mail: Nick.Jeitner@unisa.edu.au
University of Sth Australia POST: CIS, Uni Sth Aust, The Levels, SA 5095
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:10 CDT