Hi,

I have had a long running problem with hardware compression using
Omniback on HPUX 11.11. This problem has become important again.

When writing to tape using tar, hardware compression seems to work OK:
eg.
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
do
echo "FUN " $i
tar cf /dev/rmt/c1t0d0BESTn var.tar
done

Where var.tar is 1Gb of tarred up /var.

This is using DDS3 media so 12Gb uncompressed / 24Gb compressed
indicates to me that hardware compression is working.


Yet using omniback I can't write 13Gb (ordinary filesystem backup not
just the var.tar file) as it runs out of space.

I am using the same device in Omniback as for my test.
There is no compression directive in the appropriate file in
/etc/opt/omni/datalists file; it was suggested this might stop hardware
compression from working.

I see nothing in Omniback logs to indicate that hardware compression
is/is not working. In any case I am not sure that Omniback would be able
to disable it.

So, I am stumped.

Adam.

Adam Skeggs <fun@optusnet.com.au> wrote:
> Hi,
>
> I have had a long running problem with hardware compression using
> Omniback on HPUX 11.11. This problem has become important again.
>
> When writing to tape using tar, hardware compression seems to work OK:
> eg.
> for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> do
> echo "FUN " $i
> tar cf /dev/rmt/c1t0d0BESTn var.tar
> done
>
> Where var.tar is 1Gb of tarred up /var.
>
> This is using DDS3 media so 12Gb uncompressed / 24Gb compressed
> indicates to me that hardware compression is working.
>
>
> Yet using omniback I can't write 13Gb (ordinary filesystem backup not
> just the var.tar file) as it runs out of space.
>
> I am using the same device in Omniback as for my test.
> There is no compression directive in the appropriate file in
> /etc/opt/omni/datalists file; it was suggested this might stop hardware
> compression from working.

You mean there *is* a "compression deirective", but it's not turned
on, right? If not, i.e. you see no "compression directive" at all, then
look for it, because it is there (IIRC in some advanced tab) and, as you
say, it, software compression, *must* be off.

> I see nothing in Omniback logs to indicate that hardware compression
> is/is not working. In any case I am not sure that Omniback would be able
> to disable it.
>
> So, I am stumped.

Do you use the *exact same* device file, i.e. /dev/rmt/c1t0d0BESTn, in
OmniBack's device specification? If not, do a lssf(1M) on both of them
and check/report the differences.

Frank Slootweg wrote:
> Adam Skeggs <fun@optusnet.com.au> wrote:
>
>>Hi,
>>
>>I have had a long running problem with hardware compression using
>>Omniback on HPUX 11.11. This problem has become important again.
>>
>>When writing to tape using tar, hardware compression seems to work OK:
>>eg.
>>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
>>do
>> echo "FUN " $i
>> tar cf /dev/rmt/c1t0d0BESTn var.tar
>>done
>>
>>Where var.tar is 1Gb of tarred up /var.
>>
>>This is using DDS3 media so 12Gb uncompressed / 24Gb compressed
>>indicates to me that hardware compression is working.
>>
>>
>>Yet using omniback I can't write 13Gb (ordinary filesystem backup not
>>just the var.tar file) as it runs out of space.
>>
>>I am using the same device in Omniback as for my test.
>>There is no compression directive in the appropriate file in
>>/etc/opt/omni/datalists file; it was suggested this might stop hardware
>>compression from working.
>
>
> You mean there *is* a "compression deirective", but it's not turned
> on, right? If not, i.e. you see no "compression directive" at all, then
> look for it, because it is there (IIRC in some advanced tab) and, as you
> say, it, software compression, *must* be off.
>
>
>>I see nothing in Omniback logs to indicate that hardware compression
>>is/is not working. In any case I am not sure that Omniback would be able
>>to disable it.
>>
>>So, I am stumped.
>
>
> Do you use the *exact same* device file, i.e. /dev/rmt/c1t0d0BESTn, in
> OmniBack's device specification? If not, do a lssf(1M) on both of them
> and check/report the differences.

omni uses:
# lssf c1t0d0BEST
stape card instance 1 SCSI target 0 SCSI LUN 0 at&t best density
available at address 8/16/5.0.0 c1t0d0BEST

I used the norewind device for my test:
# lssf c1t0d0BESTn
stape card instance 1 SCSI target 0 SCSI LUN 0 at&t no rewind best
density available at address 8/16/5.0.0 c1t0d0BESTn

Adam.