mkfs error

[Laszlo Csizmadia]

I have a SAN library visible for two HP-UX node.
I want to have the same special file to contorll the library on both nodes. (because DataProtector is clustered...)
node1$ ioscan -fnC autoch
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
autoch 1 1/0/2/0/0.97.35.255.1.3.0 schgr CLAIMED DEVICE HP ESL9000 Series
/dev/rac/c13t3d0
node2$ ioscan -fnCautoch
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
autoch 1 1/0/2/0/0.97.35.255.1.3.0 schgr CLAIMED DEVICE HP ESL9000 Series

That's fine, so let's create a special file(c13t3d0) on node2:
node2$ mksf -v -H 1/0/2/0/0.97.35.255.1.3.0 /dev/rac/c13t3d0
mksf: Couldn't get dev number from "schgr" with options "p1": Parameter error.
mksf: Couldn't get dev number from "schgr" with options "p1b": Parameter error.

Obviously "insf -e -Cautoch" works fine but it creates the /dev/rac/c17t3d0.
How to solve this?

Thanks in advance.

[Steve Steel]

Hi


Check for the driver being in the kernel on this node


Steve Steel

[Laszlo Csizmadia]

The driver is in the kernel:
node2$ lsdev 231
Character Block Driver Class
231 29 schgr autoch

If it were not compiled in I couldn't create it with insf either.
BTW if I create the special file with insf the library works fine on node2.
E.g. mc command show the slots, etc...

[TwoProc · Accepted solution]

Since it created /dev/rac/c17t3d0 - why don't you just run a "mknod" command to create a device by the name you want with the same major and minor number as /dev/rac/c17t3d0 ?? This should fix you up...
ls -al /dev/rac/c17t3d0...
crw------- 1 bin sys 231 0x082300 Aug 13 2002 /dev/rac/c9t3d1
mknod [name your node] c 231 0x083200

now, just do an ls -al on the special file you just created. The major and minor numbers should match the one that the mksf created for the device. Now, you can proceed to use the device as you wanted.


Just an FYI - The way I tackled this was different:
for every tape device on every server on the SAN, I created a symbolic link naming the drive: D1, D2, D3, D4, etc linked to the real device names. Then, when I set up my devices in DataProtector - I only tell the systems about devices via the symbolic links, not the real device interface names. (That's the tape drives).

I did similar for the autochanger on both servers in the cluster, pointing DataProtector to /dev/autochanger instead of /dev/rac/cxtxdx. This also has the benefit of leaving a trail of sorts... to see what's linked to where.. all I have to do is "ls -al /dev | grep ^l " to see what links what devices to where.

And, just to be sure, make a backup of the /dev directory somewhere (use cpio - not tar), so that if things change on you (and they probably will), you can see what you had to put them back. This can/will happen if things get moved around in the tape library/SAN interconnects and not put back the same exact way. This can also happen if pieces of the SAN go down (lines, gbics, drives, robots) and reboot your server(s) - they will try to "fix" everything for you.

[Laszlo Csizmadia]

Good trick! I never though to use symlink in case of device files.
Thanks John!

But this mksf command should also work.