pvcreate cannot determine block size

[John Jimenez]

I issued a pvcreate and it could not determine block size, but it did give me back the prompt. I then tried to pvremove, and I am sitll waiting for the prompt. Any suggestions? Below is the output from boht

=> #pvcreate /dev/rdsk/c23t10d0
Warning: Cannot determine block size of Physical Volume "/dev/rdsk/c23t10d0".
Assuming a default value of 1024 bytes. Continuing.
pvcreate: IO error on Physical Volume device /dev/rdsk/c23t10d0: root@diamond.iehp.org:/>
=> #pvremove /dev/rdsk/c23t10d0
Warning: Cannot determine block size of Physical Volume "/dev/rdsk/c23t10d0".
Assuming a default value of 1024 bytes. Continuing.

[James R. Ferguson]

Hi John:

Your disk appears to be defunct or unreachable: IO error on Physical Volume device /dev/rdsk/c23t10d0

I'd bet that a 'diskinfo' returns a 0-size and that this fails with an error or hangs:

# dd if=/dev/dsk/c23t10d0 of=/dev/null bs=1024k count=10

Regards!

...JRF...

[Mel Burslan]

what does

diskinfo /dev/rdsk/c23t10d0

say about this disk drive of yours ?

[Vishu]

Hi John,

Just do a diskinfo and dd on that disk.

# diskinfo /dev/rdsk/c23t10d0 (Must specify its model and size)

# dd if=/dev/rdsk/c23t10d0 of=/dev/null bs=1024 (Must special equal in and out records)

Thanks

[John Jimenez]

I opened a new sessions and the dd command to that disks hangs too.

[John Jimenez]

is it okay to kill PID 19428?


=> #ps -ef | grep pvremove
root 29546 29468 0 13:48:30 pts/10 0:00 grep pvremove
root 19428 13818 0 13:16:07 pts/8 0:00 pvremove /dev/rdsk/c23t10d0

[Patrick Wallek]

You can try. But if the disk is well and truly dead, then the process will probably not die because it is waiting on an I/O that it will never receive.

[John Jimenez]

I am running HP-UX 11.11. I environment that are always growing. I usually remove the old LUN and create new Larger LUNS and assingn it a new host ID which assigns a new c#t#d#. But this time I decided to pvremove the old disk the remove special files. I then unpresented the LUN and deleted and then made a new LUN. I gave the new larger LUN the SAME host ID (c#t#d#). I did and IOSCAN and the insf command added in new special files. But maybe some old info is still there.

[James R. Ferguson]

Hi John:

> is it okay to kill PID 19428?

Yes, though you may not be able to kill it even with a 'kill -9'. If this is a device that can be physically disconnected that may help.

Regards!

...JRF...

[James R. Ferguson · Accepted solution]

Hi (again) John:

By the way, a 'pvremove' does nothing more than erase the LVM metadata on a disk. This obliterates the PVID and VGID and allows a disk to appear as if it never belonged to LVM. If you are simply reusing a disk, a 'pvcreate' is a perfectly appropriate first step.

Regards!

...JRF...

[Mel Burslan]

At this oint it does not matter if you can kill the process or not. You will need a replacement drive.

First, try

kill 19428

more than likely it will not die but do not go with -9 right off the bat

if it is still there, then try -9 option

kill -9 19428

I have a sneaking suspicion that, this will not work either. If this is a hot swappable drive, replace it while the server is alive. At this point, your pvremove command, could receive the signal it is waiting fro, from the new and functional disk drive and can complete its running. If not, it is too early to tell what the next steps might be, but most probably pvchange and vgcfgrestore will be your path.

Out of curiosity, iehp.org ?=? Inland Empire Health Plan ? If so, you must almost be my neighbor :)

[Vishu]

yes, killing this PID wont kill the process if the associated disk is dead. Removing that disk/LUN may help.

and, hanging of your DD clearly saying that disk is faulty. So, need a new disk/LUN. Get the new disk/LUN to the server and then again try pvcreate on its raw device file.

[John Jimenez]

Yes I could not kill it. I am going to try removing the 200 gig disk. If this does not work, I am going to try and create the 127 gig that used to be there and see if I can get these commands finish.

[John Jimenez]

I unpresented and removed the 200 gig LUN. I then created the 127 gig one that used to be there and introduced that one back as c23t10d0. but the pvremove or the dd is not finishing. I tried killing them both again but no luck

disk 126 1/0/2/1/0.97.8.239.1.10.0 sdisk CLAIMED DEVICE DGC CX500WDR5
/dev/dsk/c23t10d0 /dev/rdsk/c23t10d0

[Vishu]

Well John,

it is your 127 Gig LUN. so dd command may take a lot of time. use diskinfo first. if it prints good, then use dd as

# dd if=/dev/rdsk/c23t10d0 of=/dev/null bs=1024k count=1000

and wait for few mins to complete it. and paste the output.

[Bill Hassell]

When you remove a disk (LUN), you must first make sure it is no longer a part of any volume group. Always use pvchange -a N /dev/dsk/whatever to deallocate it from any volume group, then remove it from the system with rmsf (NOTE: not rm). Use the command:

rmsf -H

or use the alternate form:

rmsf -a /dev/rdsk/whatever
rmsf -a /dev/dsk/whatever

Removing /dev files for disks using rm will create problems. You need to inform the OS about hardware changes. Now you can unpresent the LUN.

Also check ioscan for NO_HW:

ioscan -f

Look for NO_HW. Then remove those paths with rmsf -H

My guess is that there are some unconnected device files in /dev/dsk and rdsk:

lssf /dev/*dsk/* | grep "???"

The ??? flags device files that have no hardware path. Use rmsf -a to remove those files too.

[John Jimenez]

Hi Bill,

Yes before I got rid of the 127 gig LUN. I successfully removed the logical volume and volume group in SAM. I then successfully pvremoved c23t10d0 and rmsf -H all for paths.
I then ioscaned to make sure that the 4 paths were removed

I then created a new 200 gig LUN and introduced it as c23t10d0. I issued the insf command and the I/O scan showed up as "claimed". But when I did the PV create I got the error, but at least got the prompt back. But because I got the error I decided to go no further and pvremove it, and that is when it locked up.

[Vishu]

untless a disk is pvcreate, there is no need to pvremove that.

so, when you remove the device file with rmsf, have you run insf -e to get them back after presenting the LUN to server.

And, what about the current diskinfo and dd(with count) command output.

[John Jimenez]

Hi Ranju, After I removed pvremoved and rmsf the old 127 gig LUN. I unpresented it and destroyed it on the EMC. I then created a new 200 gig LUN. I ran ioscan, and then I ran insf not insf -e. But when I ran insf I got the following out put.

=> #insf
insf: Installing special files for sdisk instance 127 address 1/0/2/1/0.97.4.239.1.10.0
insf: Installing special files for sdisk instance 126 address 1/0/2/1/0.97.8.239.1.10.0
insf: Installing special files for sdisk instance 148 address 1/0/4/1/0.97.4.239.1.10.0
insf: Installing special files for sdisk instance 152 address 1/0/4/1/0.97.8.239.1.10.0

I then ioscaned it again and it showed claimed, but then when I pv created it here:

=> #pvcreate /dev/rdsk/c23t10d0
Warning: Cannot determine block size of Physical Volume "/dev/rdsk/c23t10d0".
Assuming a default value of 1024 bytes. Continuing.
pvcreate: IO error on Physical Volume device /dev/rdsk/c23t10d0: root@diamond.iehp.org:/>

Are you saying that a corrupted pvcreate never took place? and there was no need to pvremove?

[John Jimenez]

I just opened up a case with HP. The pvcreate and dd have been hung for almost 4 hours and the system still seems to be running normal. Those two processes do not seem to be taking up high CPU or disk utilization. I will update you with any new information from HP. I appreciate and welcome any further comments or possible solutions.

[Bill Hassell]

The insf command added the device files because they were new to this server. However, this does not verify that the LUN is presented correctly.

> => #pvcreate /dev/rdsk/c23t10d0
Warning: Cannot determine block size of Physical Volume "/dev/rdsk/c23t10d0".
> Assuming a default value of 1024 bytes. Continuing.
> pvcreate: IO error on Physical Volume device /dev/rdsk/c23t10d0: root@diamond.iehp.org:/>

So this LUN is no good. diskinfo will either hang or return 0 bytes for size. No need to go any further. Talk with your storage admin about special requirements for HP-UX (or duplicate the settings for existing LUNs).

> Are you saying that a corrupted pvcreate never took place? and there was no need to pvremove?

With the I/O error, it is very likely nothing was written to the new LUN at all. pvremove only applies to successful pvcreate'd LUNs.

[John Jimenez]

Hi Bill,

Thanks for that info. I am storage admin. If I present this LUN as a different Host ID then I am sure it will be okay and it will be okay. But my first concern are the pvremove and dd command that are hung and I unable to kill.

not sure what you meant by duplicate the settings for existing LUNs
After the command locked. I created a new LUN the same size and setting as the one I removed. but that did not work.

[Bill Hassell]

> But my first concern are the pvremove and dd command that are hung and I unable to kill

Unfortunately, all the information you have is that I/O to the disk is not completing. You won't be able to kill the hung processes -- a feature of Unix systems when drivers do not timeout all handshake conditions.

When I mentioned duplicating an existing disk, I meant from the storage perspective. There are presentation characteristics assigned to each LUN that are different for Windows, mainframes, HP-UX, etc. When you present another LUN, validate the connection at the lowest level first, ie, ioscan, then diskinfo. If diskinfo reports 0 bytes or hangs, no need to go any further. The LUN isn't working from the HP-UX side.

[Vishu]

John, you have not pasted or told about the diskinfo command. please paste that output.

and have you checked the hardware path of that LUN, is it represting to the same device file. or check with the lssf command.

you can try other way that remove the LUN from the server but dont do rmsf. and then represent the LUN to the server. So, you will get a new device file for LUN this time. and try 'insf -e' followed by pvcreate to that raw device file assinged to it.

[John Jimenez]

Sorry here is the output

root@diamond.iehp.org:/>
=> #diskinfo /dev/rdsk/c23t10d0
diskinfo: can't SIOC_INQUIRY /dev/rdsk/c23t10d0: I/O error