On Fri, Jan 16, 2004 at 07:17:43PM -0500, Gene Heskett wrote:
> On Friday 16 January 2004 15:16, Alastair Neil wrote:
> > I just ran amtypetype -f /dev/rmt/0bn, a Sun Storedge L9 autochanger
[clip]
> Making use of software compression can beat the hardwares efficiency,
> sometimes by quite large values.
Just the usual "not everybody runs x86 Linux" comments. :-)
As always, the tradeoffs to remember are:
- With amanda, SW compression will let you get more data
on the tape, because gzip --fast will get a higher compression
ratio than HW compression, and because amanda can predict more
accurately what the compression ratio will be.
(gzip's compression ratio advantage is not nearly as great with
LTO and SDLT drives, but gzip certainly beats Alastair's DLT8000)
- If you have big disks and slow CPUs (as is arguably the case on
even the fastest Sun Enterprise server), gzip may simply not be a
viable option, because you can't afford to wait for it to
finish.
I'm not kidding. Been there, done that.
> The tape has now been written in compressed mode, so even if you turn
> the switches off, it will set it back to compressed during the tape
> recognition phase after you insert the tape.
That is not true for Solaris. With a properly configured st.conf, you
will always write exactly the density you ask for based on the device
you're calling (as tapedev) in amanda.conf. If you use Quantum's
recommended st.conf for DLT8000, for example, you will write:
/dev/rmt/0ln: 35GB uncompressed
/dev/rmt/0mn: 35GB compressed
/dev/rmt/0hn: 40GB uncompressed
/dev/rmt/0cn: 40GB compressed
/dev/rmt/0un: 40GB compressed
(For reads, the Solaris st(7D) driver will auto-read whatever density
is there regardless of what device you call.)
--
Jay Lessert jay_lessert AT accelerant DOT net
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA (fax)1.503.466.9472
|
