topic Re: Not able to remove device file for internal removed disk. in Operating System - HP-UX

Not able to remove device file for internal removed disk.

Kavita Poonia — Thu, 27 Jan 2011 08:52:41 GMT

Hello All,

I am not able to remove device file of an already re-claimed internal disk on 11iv3.

#rmsf -H 64000/0xfa00/0x19e
Device at 64000/0xfa00/0x19e is busy. Cannot remove.

#rmsf /dev/disk/disk9552
Device /dev/disk/disk9552 is busy. Cannot remove.

Thanks & regards,
Kavita

Re: Not able to remove device file for internal removed disk.

Turgay Cavdar — Thu, 27 Jan 2011 11:39:16 GMT

Hi,
Are you sure this device is not used? If the device is in open state then you can't delete it.

Regards.

Re: Not able to remove device file for internal removed disk.

Kavita Poonia — Thu, 27 Jan 2011 12:12:23 GMT

Yes, its not in use.

Re: Not able to remove device file for internal removed disk.

sarfaraj ahmad — Thu, 27 Jan 2011 12:15:26 GMT

hi,

please put ioscan and ioscan -fnC disk output.

Re: Not able to remove device file for internal removed disk.

Manix — Thu, 27 Jan 2011 13:12:44 GMT

>>an already re-claimed internal disk on 11iv3

was there any disk replacement ? if so in 11iv3 was it done on the same HW path or there was any change.

If this is not in use at all than try

Unbind a driver associated with a node corresponding to the hardware

rmsf -u -H 64000/0xfa00/0x6

Then remove with Critical Resource Analysis (CRA) report.

rmsf -c -H 64000/0xfa00/0x6

Re: Not able to remove device file for internal removed disk.

Kavita Poonia — Thu, 27 Jan 2011 13:28:21 GMT

Manix,

Yes there was a replacement for the faulted disk on this device path, after replacement new device path generated for replaced disk & this old path remained so we tried to remove it but not ablt to.

cmihx002:/root# rmsf -u -H 64000/0xfa00/0x19e
rmsf: The given device doesn't support driver unbinding feature

Also rmsf -c -H 64000/0xfa00/0x19e, is not coming up with anything as it just hangs.

Thanks & regards,
Kavita

Re: Not able to remove device file for internal removed disk.

Torsten. — Thu, 27 Jan 2011 13:31:49 GMT

Is this is SAS disk?

Did you follow the procedure for SAS disk replacements?

Maybe not.

Did you do the "pvchange -a n ..." command?

Re: Not able to remove device file for internal removed disk.

Kavita Poonia — Thu, 27 Jan 2011 14:03:23 GMT

Yes, we did....can you give us the procedure you have for SAS disk replacement ?

Re: Not able to remove device file for internal removed disk.

Turgay Cavdar — Thu, 27 Jan 2011 14:06:47 GMT

Can you post ?
# scsimgr get_info -D /dev/rdisk/disk9552
# vgdisplay -v vg_name

Re: Not able to remove device file for internal removed disk.

Torsten. — Thu, 27 Jan 2011 14:11:06 GMT

Such a sas disk always get a new device file, because it is another disk with another identifier.

After doing "pvchange -a n ..." and swap the disk, do

# sasmgr replace_tgt -D /dev/sasd0 -q old_dev=/dev/dsk/c1t4d0 -q new_tgt_hwpath=0/4/1/0.0.0.11.0

(with your own values!) to redirect the old device file to the new disk.

Then do the procedures as usual...

Re: Not able to remove device file for internal removed disk.

Turgay Cavdar — Fri, 28 Jan 2011 06:11:45 GMT

The procedure link is here:

http://www11.itrc.hp.com/service/cki/docDisplay.do?docLocale=en&docId=emr_na-c01571733

Regards.

Re: Not able to remove device file for internal removed disk.

Kavita Poonia — Fri, 28 Jan 2011 18:57:03 GMT

So what csn be the solution now ?

Re: Not able to remove device file for internal removed disk.

Torsten. — Fri, 28 Jan 2011 19:30:54 GMT

What other steps are done so far (LVM related)?

Re: Not able to remove device file for internal removed disk.

Kuntal Gupta — Sat, 29 Jan 2011 12:39:28 GMT

Remove the device files for the disk and then try rmsf -v -H ,50% chance.

I have also faced the same prob few times.
Restart will sort out the issue.

But the main prob is that if it is showing NO_HW against the disk by ioscan o/p, in that case if you add a dis /present a LUN from SAN it would not recognize.

Kuntal

Re: Not able to remove device file for internal removed disk.

jai123 — Fri, 17 Aug 2012 07:36:35 GMT

Below support doc will help you..

HP-UX 11i v3 - How to Remove Invalid Multiple Agile Device Files for a Single LUN

Information

Multiple agile DSFs seems to be assigned to the same LUN:

# ioscan -m dsf Persistent DSF Legacy DSF(s) ======================================== ... /dev/rdisk/disk416 /dev/rdsk/c0t2d0s1 /dev/rdisk/disk417 /dev/rdsk/c0t2d0s2 /dev/rdisk/disk418 /dev/rdsk/c0t2d0s3 /dev/rdisk/disk617 /dev/rdsk/c0t2d0 /dev/rdisk/disk617_p1 /dev/rdsk/c0t2d0s1 /dev/rdisk/disk617_p2 /dev/rdsk/c0t2d0s2 /dev/rdisk/disk617_p3 /dev/rdsk/c0t2d0s3 ...

The same problem shows up in the -fnN ioscan options.

Details

It has been observed that in most cases, this issue occurs after an Ignite-UX cloning process. The problem is not with Ignite-UX, the reason for this issue is very simple: The agile DSFs have duplicated major and minor numbers.

When the original image is cloned, the old device files are still there but are no longer valid device files on the new system. When the new system is installed, these old device files become just simple (stale) files located at /dev/x , OS has not registered and consequently the minor numbers are available in the new system for any new LUN that is detected.

The invalid device files might be usable, but should not be used. If for any reason the disk or tape device files are lost, can be easily recreated with insf -e , but the invalid device files would not be recreated.

Following the example above, the next output shows the duplicated minor numbers (0x######):

From /dev/disk: brw-r----- 1 bin sys 3 0x000009 Feb 3 21:15 /dev/disk/disk416 brw-r----- 1 bin sys 3 0x00000a Feb 3 21:15 /dev/disk/disk417 brw-r----- 1 bin sys 3 0x00000b Feb 3 21:15 /dev/disk/disk418 ... brw-r----- 1 bin sys 3 0x000009 Jun 7 13:36 /dev/disk/disk617_p1 brw-r----- 1 bin sys 3 0x00000a Jun 5 23:42 /dev/disk/disk617_p2 brw-r----- 1 bin sys 3 0x00000b Jun 5 23:42 /dev/disk/disk617_p3 From /dev/rdisk: crw-r----- 1 bin sys 22 0x000009 Feb 3 21:15 /dev/rdisk/disk416 crw-r----- 1 bin sys 22 0x00000a Feb 3 21:15 /dev/rdisk/disk417 crw-r----- 1 bin sys 22 0x00000b Feb 3 21:15 /dev/rdisk/disk418 ... crw-r----- 1 bin sys 22 0x000009 Jun 7 13:35 /dev/rdisk/disk617_p1 crw-r----- 1 bin sys 22 0x00000a Jun 7 16:46 /dev/rdisk/disk617_p2 crw-r----- 1 bin sys 22 0x00000b Jun 7 14:06 /dev/rdisk/disk617_p3

From this information, it is not really possible to determine which file is correct and which one is not. One could use the date or a simple analysis such as that the disk#_p# device should at least have the same disk# portion making disk617 the good file in this case.

The easiest way to fix this problem is to let the OS remove the invalid files for you. A new -x options has been added to the rmsf command on 11i v3 allowing to run this task automatically. It is recommended to run this task in early stages of the server deployment process, if not it might be possible that some of the invalid (not registered) device files are already in use by LVM in data VGs.

# rmsf -x

Another common scenario for this command is a storage reconfiguration. In that case. All the device files are known to be valid, but due to the reconfiguration and as a good practice, the old devices need to be removed. The administrator may accomplish this task by removing one file at a time or just using the rmsf with the -x option.

The execution of the above command should fix most of the cases explained in this article. This article already mentioned in http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=3367813&prodTypeId=18964&objectID=c02254626

Regards ,

jay