Chris Cruft

The IMD is a cool little hardware device that displays information directly on a small LCD screen.  Type information displayed includes maintenance messages, warnings and errors of all kinds, including:

During the hardware POST, progress messages are displayed.

Basic system information, including user-defined info statically configured in the BIOS, is displayed in a simple menu structure.

Integrated Management Log events are displayed -these are the same events that can be seen in the using cpqimlview or the IML viewer built into the Remote Insight board.

I found a cool little utility, tapecat, while browsing the amanda wiki.  It shows the contents of a tape (with extra detail for amanda files).

# tapecat

References:

http://www.inventivetechnology.at/tapecat/

Compression in tape drives is a mess -few standards, ridiculous marketing claims, nasty traps that kill capacity/performance and much missing knowledge.  Of these, the lack of Linux standards for managing compression seems to be the most egregious barrier to productivity.

First problem: Some tape drives enable compression based on density commands, others by explicit compression commands.  I assume these commands are SCSI standards…  Example: DDS drives accept explicit compression commands.  DLT drives use density commands.

Second problem: Many tape drives will reset compression status after a pre-recorded tape has been inserted.  This can be helpful when reading a combination of compressed and uncompressed tapes in a drive.  But it can really confuse the issue if you are reading and writing tapes.

Third Problem: There are no standard commands or devices for managing compression under Linux.

In order to bring a measure of sanity to this situation, I am moving a tres grand vitesse towards stinit.  With stinit, a configuration file is used to define up to four operating parameter sets (called modes) for each tape device.  Each mode becomes a Linux device (st0, st0a, st0l, st0m).  The theory of stinit is that the operating system will enforce the mode settings (including compression and density) every time the device is accessed.  It is important that stinit be executed at boot time, or the devices either won’t exist, or won’t be set on access.  I’ve accomplished this by adding stinit to /etc/rc.d/rc.local:

Screen clipping taken: 21/07/2006, 10:04

References:

http://wiki.zmanda.com/index.php/Hardware_compression

I noticed that my tape backups were failing lately when backing up the /home partition on triumph.  To be certain of the problem, I ran a backup of just that disk:

# su amanda -c “amdump CCH1 triumph.hapgoods.com /home”

The results confirmed that I am running out of tape when backing up this (large) disk:

*** THE DUMPS DID NOT FINISH PROPERLY!

These dumps were to tape CCH103.

*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].

Some dumps may have been left in the holding disk.

Run amflush to flush them to tape.

The next tape Amanda expects to use is: CCH106.

FAILURE AND STRANGE DUMP SUMMARY:

triumph.ha /home lev 0 FAILED [”data write: Connection reset by peer”]

triumph.ha /home lev 0 FAILED [out of tape]

The filesystem is 33168876 blocks long -or about 32GB.  Way too big to fit in the holding space, so the backup goes directly to tape and I don’t even have a disk image to fall back on.  But here is the funny part -the file system may be close to the 35GB native capacity of the tape drive*, but it is nowhere near the 70GB compressed capacity of the drive.  So why is the drive not compressing?

*Remember that tape drive capacity is expressed in marketing GBs (mGB), or billions of bytes.  1GB = 1.0737mGB.  So any normal size has to be increased by about 7.4% to get the marketing capacity.  In this case, 32GB ~= 35.6mGB.

Well, it turns out that the tape drives had not been properly initialized by stinit.  I have written more on this subject under stinit.  But unfortunately, I think the tapes will now always be written in uncompressed format because the header is uncompressed.

References:

http://www.mail-archive.com/amanda-users@amanda.org/msg25045.html

I have had difficulty deciphering the meaning of several of the security settings of the ProLiant.  Here is a decent reference from a newer ProLiant’s User Guide:

http://www.csc.fi/proj/mgrid/docs/hp/dl585_user_guide.pdf

Screen clipping taken: 21/07/2006, 16:35

I’m pretty sure these are the same settings with the same meaning as the ProLiant 3000.