On Thu May 1 2003 10:44, Jon LaBadie wrote:
>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?
And excelent question Jon. But any answers you can deduce from
experimentation would obviously be limited to Solaris systems I'd
think. I've no idea if the drive itself can be switched in mid
stream like that. Even that may well be highly drive specific.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
