Not able to remove device file for internal removed disk.

[Kavita Poonia]

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

[Turgay Cavdar]

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

Regards.

[Kavita Poonia]

Yes, its not in use.

[sarfaraj ahmad]

hi,

please put ioscan and ioscan -fnC disk output.

[Manix]

>>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

[Kavita Poonia]

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

[Torsten.]

Is this is SAS disk?


Did you follow the procedure for SAS disk replacements?

Maybe not.


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

[Kavita Poonia]

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

[Turgay Cavdar]

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

[Torsten. · Accepted solution]

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...

[Turgay Cavdar]

The procedure link is here:

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



Regards.

[Kavita Poonia]

So what csn be the solution now ?

[Torsten.]

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

[Kuntal Gupta]

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

[jai123]

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