Amanda-Users

Insight into compression problem (was Re: planner question)

2003-05-01 10:45:53
Subject: Insight into compression problem (was Re: planner question)
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Thu, 1 May 2003 10:44:10 -0400
On Thu, May 01, 2003 at 09:40:46AM +0200, Paul Bijnens wrote:
> Greg Troxel wrote:
> 
> >[dropping list]
> >
> >Thanks.  Some of that is ancient history, and I have dds3 drive that I
> >dip-switched to no compression.
> >
> >Do you mean to say that a tape that was once written compressed will
> >be (re)written compressed even on a drive jumpered for no compression?
> >
> When you insert a tape in a drive, and read it, the drive adjusts itself
> to the settings of that tape. That means that if it was written with hardware
> compression the drive sets itself accordingly, even if it was set to no hw 
> compr.


I'm not about to disassemble my external tape drive to test this,
but I wonder...  Guessing that Greg has an HP drive as do I, the dip switches
control two things, what compression mode is entered on power up and whether
that mode can be switched by software.  I wonder if turning off the "software
control" also includes the drive's builtin software?  I just don't know.

> This is exactly what happens with an Amanda tape that was labeled with hw 
> compr.
> Amanda verifies the label, and thus implicitly sets hw compr if the label
> was written as such.  To get rid of hw compr tapes, you have to insert the 
> tape,
> execute the command to  disable hw compr, and write to the tape WITHOUT
> first reading it.  Amlabel first reads the tape, so you cannot use that one.
> Something like this works:
> 
>     $ mt compression off
>     $ mt status
>          (verify compression status and blocksize (0 = var, is best))
>     $ dd bs=32k count=10 if=/dev/zero of=/dev/your/tape
>     $ amlabel YouConfig OLDLABEL45
>         (probably add -f to force)


And here is the "insight" promised by my Subject line.  I have always been 
curious
why Gene and others encountered this problem and yet it seemed like a 
"non-problem"
to me (and others?).

The difference, I believe, is the way Solaris and some OS's handle setting the
compression compared to Linux and other OS's.  My Solaris mt command has no
"compression" command.  The reason is I select compression upon opening the
tape drive by specifying different devices.  For example, /dev/rmt/0l for
"low" density (no compression for me) and /dev/rmt/0c for "compression".

If I mistakenly "amlabel" a tape with the 0c device, I can relabel it with
0l without the complex scheme shown above.  When I'm `relabeling' the tape,
I'm sure amlabel starts the drive in no-compression mode.  Amlabel then
reads the header.  Perhaps the drive switches to compression mode with its
auto-sensing.  Without checking the source code I can't be sure, but I suspect
that amlabel then closes the tape drive and re-opens it for rewind and/or 
writing.
This reopening of the 0l device again causes the drive to switch to 
no-compression
mode for writing the new header.

Effectively, each reopen of my tape device '0l' does an 'mt compression off'.

I wonder then, not for amanda, just generically, if I could open the no-rewind,
no-compression device and write a tape file or two.  Leaving the tape where it
is, open the no-rewind, compression device and write more tape files.  I.e.,
can the tape contain a mixture of no-hw-compressed and hw-compressed tape files
and still work properly?


-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

<Prev in Thread] Current Thread [Next in Thread>