how to see the activity of tape devices

[Jdamian]

Hi.

I'm trying to see the activity (kBytes per second) of my tape drives when a backup is running. But neither sar nor iostat nor glance report that, they all report disk activity.

How can I see the tape activity ?

Thanx in advance

[Stefan Farrelly]

I dont believe you can see it. The only way using simple backup programs like tar,cpio,fbackup is to wait until the backup completes then do some math to calculate what the overall transfer rate was.

If you use a high level, but expensive, backup tool such as Omniback, Netbackup or Networker then these show you the transfer rate as the backup progresses (in stages).

[Dietmar Konermann]

Using Glance you could select the process that writes to the tape device. Then choose the "open files".option .. and watch the increasing offset metric for the tape device special file.

Best regards...
Dietmar.

[Jdamian]

OmniBack-II (=OB2) is the application that makes the backup, but, for me, it is not reliable because the backup data amount is near 650 GB (raw data because near 110 raw lvols are backed up) and OB2 fits this data in four DLT-80GB cartridges (4 x 80GB = 320 GB)...

I think OB2 uses a run-length encode algorithm (or any other compression method) to dump those 650 GB into the 4 cartridges.

P.D: in my OB2 configurations, the checkboxes 'compress' and 'encode' are disabled.

[Robert-Jan Goossens]

Did you check compression on the hardware ?

Robert-Jan.

[Stefan Farrelly]

Dietmar's reply was very interesting.

Ive found that in glance if you monitor the fbackupwrtr process and the offset for the tape drive over 60 seconds it does seem to accuately report the amount of data going to the DLT drive, ie. on our DLT7000 it adds up to around 38GB/hr which is accurate - our daily fbackup backups get around the same figure.

However, using lsof to monitor the same fbackupwrtr process and its offset seems to report different figures over 60 seconds. Ive been monitoring a backup now and calculating the difference in offset (its in hex) and in terms of GB/Hr its reporting around 34 GB/hr, pretty close. You could easily write a script to monitor this using lsof.

[Jdamian]

Robert-Jans, how can I check if a DLT8000 drive is compressing data (= hardware compression) ?

[Dietmar Konermann]

If the checkboxes "compress" and "encode" are not checked, the OB2 sends the _plain_ data to the device, adding some overhead to each block - which is not too much.

So the offset of the tape should refect somehow the amount of backed up data. Assuming that the drive does HW compression (i.e. you use a device special that allos HW compression like *BEST*), then of course you may see much more date going to the drive than expected.

As a test you can dd from /dev/zero to the compressing drive and watch how much zeros can fit on that medium! :-) Simply, because the stream can be compressed efficiently.

Maybe, your raw device's contents can be compressed quite easily. There is a "tapeinfo" tool available that allows you to read the drive's compression statistics. Let me know if you are interested in this tool (forename.surname@hp.com).

Best regards...
Dietmar.

[Robert-Jan Goossens]

Hi,

http://quantum.broaddaylight.com/quantum/FAQ_17_183.shtm

and since you use raw devices there could be a higher compression ratio.

Hope it helps,

Robert-Jan.

[Stefan Farrelly · Accepted solution]

You check the compression by looking at the device file you are using, eg;
lssf /dev/rmt/XXX

If it says best density then compression is on. You can be sure by creating a new /dev/rmt file with mksf (see man mksf - there are the options for compression or no comperssion for a tape device, so you could create new device files with/without compression and then write to them).

I have a script now to monitor the speed data is being written to a tape drive;

let x=$(lsof|grep "/dev/rmt"|awk '{print $7}')
while true
do
sleep 60
let z=$(lsof|grep "/dev/rmt"|awk '{print $7}')
let y=$z-$x
let y=$y/1000000
let u=$y/60;echo "${y} Mb/min, ${u} Mb/sec over last minute"
let x=$z
done


All you need is lsof installed and a current backup running at the time to a /dev/rmt device.

[Leif Halvarsson_2]

Hi,
You should distinguish between hardware and software compression, OmniBack can use both. If hardware compression is on and software compression off (which should be normal) you can rely on the data amount OmniBack displays, this is the data actually sent to the drive. The drive then uses an internal compression algorithm (LZW) to compress the data which in your case makes it possible to fit 650 GB data on four cartridges.

[Robert-Jan Goossens]

Stefan,

Thanks for the script (brilliant)

Kind regards,

Robert-Jan.

0 points please