On Tue March 11 2003 09:19, Eric Sproul wrote:
>On Mon, 2003-03-10 at 20:36, Gene Heskett wrote:
>> On Mon March 10 2003 14:13, Eric Sproul wrote:
>> >My question: If I do a dd of some amount of data (like dumping
>> > the first 32K of data as I would if I was saving the label),
>> > and then see (via mt) that the drive's compression is still
>> > off, is it safe to conclude that the tape was written with
>> > compression off?
>>
>> I believe so. If the drive has a front panel indicator of
>> compression use like mine does, I'd use that for the last word.
>
>I don't believe it has an LED for that, but it's hard for me to
> see them, as the drive is buried in the dark recesses of a
> rackmount library with only a small viewing window that is mostly
> blocked by the robot mechanism. I'll have a look in the
> manual...
Thats right on the front face of the magazine drawer in my
Seagate/Compaq changer, and its called 'DC' meaning Data
Compression. Not all drive combo's will have it that handy though.
Those DDS drives that have a 3rd led on the front panel, which in
your case is probably not installed as it would interfere with the
robot, might use one of them for this indicator, but even that
seems to be a crap-shoot as everybody has their own ideas about
what might be important to the user, and what might generate
needless phone calls to support.
><"Jeopardy" music>
>
>OK, according to the manual, the only density-related indicator
> present is the one indicating whether the tape is SDLT110/220
> (lit) or SDLT160/320 (unlit). No light for the compression
> setting.
>
>> >BTW, the drive has no DIP switches for setting compression--
>>
>> That would definitely be unusual... The lawyers have attacked
>> the user stuff in the packaging to the point where it may not be
>> mentioned (I mean "Now why would the *user* need to know that?),
>> and I'd come a lot closer to being able to believe that as
>> opposed to its not having any jumpers or dip switches at all to
>> control its powerup defaults.
>
>This is a Compaq SDLT320 drive. According to the reference guide:
>
>"The SDLT drive ships from the factory with data compression
> enabled for writing. In this mode, data is always compressed when
> writing to the tape, but the drive is capable of reading both
> compressed and native tapes. For the drive to write native data,
> the data compression setting must be changed through the
> software. To change the setting, consult the backup application
> software documentation for the data compression enabling and
> disabling procedure."
>
>Believe it or not, it's software-only. From a visual inspection
> of the library, the part of the drive visible from the rear has
> no switches.
Ahh, well... I just knew it would someday come to this :-)
But to look on the bright side, at least the manual was nice enough
to tell you that.
>> > it is
>> >completely controlled by software. Also, my system is Linux,
>> > so there are no compression-related device names. I am
>> > relying strictly on mt to manipulate the drive outside of
>> > AMANDA, so it's important that I be able to trust its output.
>>
>> How are you interpreting the mt report so as to define if
>> compression is on or off? I don't recall seeing that in plain
>> english in any mt output report since about RH5.2, and it has
>> changed a bit. Its concise to the point of being obtuse IMO.
>
>Well, GNU mt (the one with the "datcompression" option) would
> report the compression status if you left out the on/off
> argument. So that's how I was figuring it. However, the mt-st
> version will set the compression *on* if you throw it
> "compression" without also saying "on" or "off". I've switched to
> using tapeinfo from mtx (at Joshua's suggestion), which reports
> much nicer information:
Yes it does. In that regard, mt most certainly does need help.
># tapeinfo -f /dev/sg3
>Product Type: Tape Drive
>Vendor ID: 'COMPAQ '
>Product ID: 'SDLT320 '
>Revision: '2E2E'
>Attached Changer: No
>SerialNumber: 'PMC24Y0940 '
>MinBlock:4
>MaxBlock:16777212
>SCSI ID: 1
>SCSI LUN: 0
>Ready: yes
>BufferedMode: yes
>Medium Type: 0x86
>Density Code: 0x49
>BlockSize: 0
>DataCompEnabled: no
>DataCompCapable: yes
>DataDeCompEnabled: yes
>CompType: 0x10
>DeCompType: 0x10
>Block Position: 202559
>
>"DataCompEnabled: no" is about as plain as you can get. :)
Yup! And it sounds as if you have a handle on this problem too :)
--
Cheers Eric, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.24% setiathome rank, not too shabby for a WV hillbilly
|
