1832823
Members
3841
Online
110045
Solutions
SOLVED
The first drive is SCSI connected, the others are on SAN.
Please provide following info
# model
# ioscan -fn
Hope this helps!
Regards
Torsten.
__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.
__________________________________________________
No support by private messages. Please ask the forum!
If you feel this was helpful please click the KUDOS! thumb below!
Please provide following info
# model
# ioscan -fn
Hope this helps!
Regards
Torsten.
__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.
__________________________________________________
No support by private messages. Please ask the forum!
If you feel this was helpful please click the KUDOS! thumb below!
Can you post the information I asked you for?
Hope this helps!
Regards
Torsten.
__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.
__________________________________________________
No support by private messages. Please ask the forum!
If you feel this was helpful please click the KUDOS! thumb below!
Hope this helps!
Regards
Torsten.
__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.
__________________________________________________
No support by private messages. Please ask the forum!
If you feel this was helpful please click the KUDOS! thumb below!
Piyush,
It's not totally clear what your problem here is...
You must already have the patch which adds st_san_safe as otherwise you wouldn't see that kernel parameter at all.
The behaviour of st_san_safe is very simple... it stops you from opening rewind-on-close device files for all devices of type stape.
So in your output above for example it would stop you using /dev/rmt/4m and /dev/rmt/3m as they are rewind-on-close devices, but you can still use /dev/rmt/3mn and /dev/rmt/4mn.
However I'm guessing your problem is that for the first tape drive (The HP one rather than the IBM one), your problem is that you're not seeing the expected /dev/rmt/5mn listed in the output of ioscan yes?
This is probably just because you have some old device files hanging around in /dev/rmt which have prevented insf from creating the correct new device files. To fix this, do the following:
1. Run the command:
lssf /dev/rmt/* | grep \?\?\?
This will list old tape device files that no longer have a physical device associated with them.
2. Delete all the device files that you get from the lssf command listed above (you're supposed to use rmsf to do this, but rm is fine too)
3. Run the following command to regenerate any missing device files:
insf -e
4. Repeat your ioscan and see if you can see your device correctly now.
But of course remember that you *must* use the no-rewind-on-close device files (such as /dev/rmt/5mn) as long as you have st_san_safe set to 1.
Incidentally and not related to your problem, I note that the other devices are IBM tape drives, yet you are using the HP stape device driver. For most implementations I see with IBM tape drives, customers tend to get better results with IBM's own atdd device driver available from here:
ftp://ftp.software.ibm.com/storage/devdrvr/HPUX/11i_PCI/
(as you are on 11.11 I expect you'd get the 3.x version)
HTH
Duncan
I am an HPE Employee
It's not totally clear what your problem here is...
You must already have the patch which adds st_san_safe as otherwise you wouldn't see that kernel parameter at all.
The behaviour of st_san_safe is very simple... it stops you from opening rewind-on-close device files for all devices of type stape.
So in your output above for example it would stop you using /dev/rmt/4m and /dev/rmt/3m as they are rewind-on-close devices, but you can still use /dev/rmt/3mn and /dev/rmt/4mn.
However I'm guessing your problem is that for the first tape drive (The HP one rather than the IBM one), your problem is that you're not seeing the expected /dev/rmt/5mn listed in the output of ioscan yes?
This is probably just because you have some old device files hanging around in /dev/rmt which have prevented insf from creating the correct new device files. To fix this, do the following:
1. Run the command:
lssf /dev/rmt/* | grep \?\?\?
This will list old tape device files that no longer have a physical device associated with them.
2. Delete all the device files that you get from the lssf command listed above (you're supposed to use rmsf to do this, but rm is fine too)
3. Run the following command to regenerate any missing device files:
insf -e
4. Repeat your ioscan and see if you can see your device correctly now.
But of course remember that you *must* use the no-rewind-on-close device files (such as /dev/rmt/5mn) as long as you have st_san_safe set to 1.
Incidentally and not related to your problem, I note that the other devices are IBM tape drives, yet you are using the HP stape device driver. For most implementations I see with IBM tape drives, customers tend to get better results with IBM's own atdd device driver available from here:
ftp://ftp.software.ibm.com/storage/devdrvr/HPUX/11i_PCI/
(as you are on 11.11 I expect you'd get the 3.x version)
HTH
Duncan
I am an HPE Employee
Yes, if there was for instance an old file in the /dev/rmt directory called 5mn, but the device minor number for that file didn't point to hardware path 0/0/1/0.1.0, then just running insf would acheive nothing. If the file is removed and insf re-run, everything should sort itself out.
HTH
Duncan
I am an HPE Employee
HTH
Duncan
I am an HPE Employee