On Fri, Sep 09, 2005 at 05:26:39PM +0200, Paul Bijnens wrote:
> Jon LaBadie wrote:
> >I don't think it is actually a 'flag', but merely the presence of HW
> >compressed data at the front of the tape.  The compression setting
> >is only relevant when writing tapes.  Reading switches automatically
> >based on the type of data (HW compressed or not) written before.
> >And that "auto switch" is what causes the problem.  You set the
> >tape to compression off, read a bit of compressed data (like the
> >amanda label at the start of the tape previously written with
> >compression on) and the drive "auto switches" to compression on.
> >
> >To clear this state for amanda you have to write a bunch of data
> >at the beginning of the tape, after setting compression off, and
> >be sure to not read anything between the two.
> 
> 
> The good news is, that when I try to reproduce the problem, I cannot
> (anymore).
> 
> A few years ago, I struggled with the compression settings of my
> tape drive (a DDS-2 drive), and I used sequences like below
> to test the hardware compression status of the drive.
> It was then that I added the hwcompr test heuristics to amtapetype,
> at that time still called "tapetype".
> I'm not 100% sure, but I believe I used a Linux kernel 2.4.18.
> 
> I try to reproduce the problem now, but my current config does NOT
> autoswitch after reading a tape:
> 
> $ mt -f /dev/st2 compression 1
> $ amtapetype -oc -f /dev/st2
>    ... yes hw compression enabled
> $ mt -f /dev/st2 compression 0
> $ amtapetype -oc -f /dev/st2
>    ... no warning about hw compression!!!
> 
> Amtapetype does read the tape before writing!  I even added a
> "dd if=/dev/st2 of=/dev/null bs=32k" inbetween, and still got
> same result.
> 
> That either means that phase of the moon is correct for handling of
> tapes, or that current versions of Linux do not have the problem
> anymore.  It tried it both on a 2.4.20 kernel and a 2.6.9 kernel,
> and both do not autoswitch for writing (they do for reading, just as
> expected).
> 
> Can anyone still reproduce the problem?  And under what circumstances?

Not being a linux tape user I'm not sure, but wasn't there some change
in the way scsi tape control information could be set a while back?
Maybe there was a new driver introduced that stores the settings and
reapplies them on open for write.

I've always wondered why we never heard the opposite problem.  I.e.
people who had used software compression and now are trying hardware
compression but it doesn't seem to be working.  Amanda would read
the uncompressed data and the drive would switch off compression
before anything was written.  But I don't recall any such reports.

-- 
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)