Diskinfo reporting incorrect size for EMC LUN

[Xavier Gutierrez_2]

Dear folks.

We are facing the following issue:

We just got a bunch of BCV devices assigned by the storage group. All of them are 32GB but one shows up in diskinfo as being 64GB.

The problem is that the OS believes so:
You can pvcreate the disk, create a vg using it and a Lvol and will show 64GB. But the very moment you try to "newfs" on it, it fails when trying to read beyond 32GB.

On the other hand, INQ utility from EMC shows 32GB.

We believe the problem comes from the HW/Path of this disk was used before for a 64GB LUN and that information is still somehow in the kernel.

Any clue on how to solve this?

For now we are going to try un-assigning the disk, re-scanning the bus, removing special files and starting from there.


Cheers,

Xavier.-

[Steven E. Protter]

Shalom Xavier,

Few options.

If the LUN has recently been extended, you may need to reboot to get the new space recognized.

Playing around with ioscan may get the space recognized.

Check the fcmsutil and make sure the WWN is the same as assigned on the EMC.

What does lvdisplay show for space?

SEP

[Xavier Gutierrez_2]

Hi, Steve.

We even tried to use the "replace_dsk" command inside fcmsutil (just in case it was a problem of the FC HBA internal cache) with no luck.

Already played with ioscan for about an hour or so ;-)

We are having the storage group un-assigning the volume. At that time, we'll remove the special files and any other trace of the device (powermt check, etc).

Then, we'll have them assign it again and we'll cross our fingers and pray...

If not, I guess reboot can be a solution but unacceptable from a business point fo view right now...


Thanks in any case,

X.-

[Xavier Gutierrez_2]

Oops, I forgot to say that lvdisplay shows the 64GB... AMAZING!

[John Guster]

I would let SAN guy take that disk back, re cooked, then assign to the server. Sounds like SAN guy messed up with this LUN. ooops.

[Jeff_Traigle]

You said you played with ioscan, but did you ever run "insf -eC disk" or "insf -eH insert_HW_path_here" to update the device files?

[Jannik]

First:
# pvcreate -f /dev/rdsk/XXXXXX

Second:

It is the lvm information you have a problem with...
dd if=/dev/null of=/dev/rdsk/XXXXXX
This command will delete the header of the disk.

And let it run for a some time 1 min.
when you should be able to do your:
# pvcreate -f /dev/rdsk/XXXXXX

You could try to do a:
rmsf -eH
ioscan
insf -eC disk

But then it would still hold the lvm information. You need to do the dd command to make sure the the LVM information is deleted.

You may be able to do a pvremove but the dd works :-) You have to do it all the time with VxVM.

[Geoff Wild]

remove it from the vg

rmsf -H

then insf -eC disk

Now what does diskinfo show?

Rgds...Geoff

[Denver Osborn · Accepted solution]

Hi Xavier,

I had a similar problem a few years ago after resizing a lun. If you care to read, here's the post.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=846401

I honestly don't remember what was done to fix it, but could be we ended up bouncing the box as the only option.

I'm pretty sure the problem had something to do with VxVM. Narrowing your search results to VxVM specific stuff might help.

-denver

[Xavier Gutierrez_2]

Hello everyone.

Let me reply one by one:

John Guster: Like I said, that's our action plan as of now.

Jeff Traigle: Yes, we did the RMSF and the INSF *several* times before even trying to create the test vg to see if LVM actually saw the true size of the disk.

Jannik: We've already done this with no luck. We dd'ed the headers a couple of times already.

Geoff Wild: We tried the RMSF and the INSF before even thinking of creating a test VG to see what LVM had to say.

Denver Osborn: This system has vxvm installed although we do not use it. However, it starts up at boot-up time and vxiod is currently running. We'll try to kill vxiod in any manner before actually bouncing the box when we get downtime from the user community. I'll leave your points un-assigned until we try that because something is telling me you deserve a bunny!

Thanks everyone in any case for the suggestions.

Best regards,

X.-

[Duncan Edmonstone]

Xavier,

If you previously had another LUN at that HW path of a different size then from the OS perspective this is going to appear as an 'online resize' of a LUN. HP-UX/LVM doesn't support this currently (although I think you can do it with the latest VxVM versions). As Denver has indicated, the only resolution is reboot -or- have the SAN guys re-present the LUN at another vbus-target-lun that hasn't been used before.

Online resize will be supported in 11iv3 due for release in a month or so (where the whole IO stack has been re-engineered).

HTH

Duncan

[Xavier Gutierrez_2]

Finally we had to bounce the box to get it to work.

In the mean time, our storage guys assigned the LUN with differen port? id so it got different HW path.

Thanks to everyone,

XG.-