tape device files

[Eric Locsin]

I'm having issues using compression on virtual tape drives from EMC's Clariion Disk Library. The EMC engineers are telling me to use the Sun format for tape devices /dev/rmt/0cbn. I keep telling them that HPUX doesn't use that format. The tape device files I'm using are in the format /dev/rmt/c18t2d1BESTnb. I'm pretty sure that is the correct device file for using compression (if available) on HPUX.
Does anyone know if we can create a tape device file in HPUX using the Sun format?

[Stephen Keane]

The name of the device file is merely a convention, it's the major/minor number of the device file that determine its behaviour. You can call your tape device file fred if you want!

Do you EMC engineers know what the behaviour of a Sun format tape drive is, in terms of density/Berkley-ness/rewindability etc?

[Eric Locsin]

no-rewind, Berkley, highest density with compression enabled.

[Peter Godron]

Eric,
you could either create a soft link with ln or
use mksf to create the file you want
example:
/sbin/mksf -d stape -I 12 -u -n -b BEST rmt/12mnb
Regards

[Bharat Katkar]

Hi,
As peter already suggested you can create the soft link ...

# ln -s /dev/rmt/c18t2d1BESTnb /dev/rmt/0cbn

Hope that helps,
Regards,

[Stephen Keane]

It might also be interesting to issue an mt status command

# mt -f /dev/rmt/c18t2d1BESTnb status

or

# mt -f /dev/rmt/0cbn status

and see if compression comes up as enabled, especially as you are talking about virtual tape drives.

[Eric Locsin]

Thanks. I created the new device file but I'm still kind of clueless as how this will behave differently than say /dev/rmt/c18t2d1BESTnb. I really don't understand why EMC would think /dev/rmt/0cbn would enable compression when /dev/rmt/c18t2d1BESTnb doesn't. As you've all stated, it's just a name to HPUX.

[Stephen Keane]

HP-UX looks at the minor number to determine the capabilities of the drive. Perhaps EMC uses the actual device name (sloppy)?

[Eric Locsin]

This is what I get from the "mt" output:

Drive: IBM ULTRIUM-TD2
Format:
Status: [0]
File: 0
Block: 0

This is what I get from "lssf" on both device files:
stape card instance 18 SCSI target 2 SCSI LUND 1 berkely no rewind density available at ...

[Stephen Keane]

This is what I get on a Sony drive

$ mt -f /dev/rmt/0m status
Drive: SONY SDX-300C
Format: Sony AIT
Status: [41113000] BOT online compression immediate-report-mode
File: 0
Block: 0


Note the 'compression' entry. Perhaps the virtual tape drives do not conform? What are your major/minor numbers?

[RAC_1]

Linking the file is not a soltion here. run the lssof (or sun equivalent) on the device file that sun uses for backups.

Run lssof on hp-ux device file. It shoulf show you comprssed/best density info.

Anil

[RAC_1]

Linking the file is not a soltion here. run the lssf (or sun equivalent) on the device file that sun uses for backups.

Run lssf on hp-ux device file. It shoulf show you comprssed/best density info.

Anil

[A. Clay Stephenson]

Actually on systems after 10.0, the same minor number can mean different things to different drives. There are simply more data to be encoded than there are minor device number bits. HP-UX's trick is to modify a drivers internal properties table and part of the minor number serves as an index into this property table. The mksf command alters both the minor device number and the internal property table. So, ... it is possible that tape drives having identical major/minor device tuples on two different hosts would behave quite differently. Man 7 mt for details.

[Eric Locsin]

crw-rw-rw- 2 bin bin 205 0x1221c0 Jan 25 03:02 /dev/rmt/c18t2d1BESTnb

I know the virtual tape drive works. I used it on a Win2K server prior to moving it to the HPUX server. I was getting over 400 GB on a virtual tape.

I opened up a case with HP. I'm waiting for a call back.