resized LUN but diskinfo shows old size

[Denver Osborn]

Hi all,

I've got an hpux 11.11 box w/ fabric attached VA7100. One of the LUNs was resized from 9GB to 2GB, but diskinfo still reports it as 9GB. It looks to me like the driver has the info cached somewhere. Any suggestions on how I might correct this problem without bouncing the box?

Yes, the LUN is 2GB now... armdsp shows the correct info.

I also saw there was a SCSI patch for a similar issue back w/ 10.20 and 11.0, so I'd hope the problem fix was included when 11.11 rolled out.

Thanks,
-denver

[Florian Heigl (new acc)]

A few weeks ago I read a statement by S. Potter, who said he only *once* managed to get a LUN size change noted.

Our standard procedure also always is based on adding a LUN of the new size and pvmove'ing.

Unless someone knows the trick, I'd recommend You to go back to 9GB size (for safety in case LVM still assumes extents there) and adding another LUN + moving the data with pvmove, or maybe even mirroring it for a moment. afterwards You can throw out the 9GB lun. This will work online, the only critical point is what happens, when the PE's >2GB are being accessed, but I'd say that the risk isn't too high.

If You're in doubt, let hp look over the LUN with the lvmux11 utility.

[Denver Osborn]

let me add that this disk is not in use by the system, there's no data on it and it's not an LVM disk.

A few nodes have access to the LUN. One node's diskinfo shows the LUN as 2GB, while another shows 9GB. I think the admin resizing the lun did diskinfo prior to resizing. So it would make sense that the idle box showed the new 2GB size -vs- 9GB because it actually queried instead of pulling from cache. Does this make sens?

Any how, I'm hoping someone might know a way it can be cleaned up without a reboot.

[Uday_S_Ankolekar]

I thought lun can not be resized once created.
Delete the the lun completely and recreate it with desired size.
I will create new lun and move data to new lun and delete the old one.

-USA..

[Patrick Wallek]

Have you tried removing the rmsf'ing the device file and the insf'ing to recreate it?

I ran into something similar when I deleted a LUN and then recreated it at a smaller sizeon a VA7400. I can't remember what I did to solve the problem though.

[Denver Osborn]

sorry, the lun wasn't "resized" it was deleted then created with with the newer size...

I've tried rmsf, ioscan, insf and nothing seems to do it.

rmsf -k -H hw_path (and rmsf -a /dev/rdsk/cxtxdx)
ioscan
insf -e

[Geoff Wild]

If you have rmsf'd, ioscan -fnC disk, and insf -e -C disk - and it still shows as 9gb? well, are you positive you are looking at the same disk?

Rgds...Geoff

[Steven E. Protter]

I've had constant problems in this arena, and as noted only once got a box to recognize increased space without a boot. I do not know what I did special to make that happen.

Unfortuneately, the only process I know works involves destructive removal of the logical volume.

lvremove
vgreduce
pvcreate
vgextend

This problem generally occurs with non-HP disk arrays.

SEP

[Denver Osborn]

yes, I know it's the same disk :)

I'm working on a passive node and just tried

rmsf -k -H 0/4/0/0
ioscan
insf -e

and again I've got nuthin...

I really was hoping not to bounce the box for this. Maybe I'll try one last time to remove and recreate the LUN.

[Patrick Wallek]

Denver,

What about --

1) Remove LUN from VA
2) Run diskinfo on non-existant LUN. You *should* get an error.
3) rmsf device files
4) recreate LUN
5) ioscan and insf to recreate device files
6) run diskinfo again.

If the info is cached somewherre maybe running the diskinfo and having it error (hopefully) will clear that.

[Florian Heigl (new acc)]

Denver - ok, good to hear there was no data on it :)

I don't know why this is happening, but I'm afraid that the disk won't be rescanned before You remove it again on the VA, and then remove the special files and wait for the kernel to drop it from ioscan.

Short of a reboot (and that shouldn't be neccessary), I can't tell for sure, even when scratching my head.

I've not yet seen diskinfo lying to me in such situations.

the patches interesting would be both scsi and 'ioscan performance' and the likes.

[Denver Osborn]

Thanks for the thought Patrick

I tried...

removing the lun
ioscan
diskinfo (still resturned info for removed lun)
rmsf -k -H hw_path
ioscan
diskinfo --> failed
created lun
ioscan
insf
diskinfo --> 9GB. doh!

Maybe I forgot to blink 3 times and clap my hands before running the last ioscan.

It's about time to call HP so the RC can tell me to install a patch that will require a reboot and magically fix my problem. :)

-denver

[Geoff Wild]

Yes - I would call HP - doesn't make any sense - this isn't Windoze after all - a reboot should not be required :0

What about this - can you leave that LUN there - then create a new LUN of 2 gb's - and check it with diskinfo?

Then remove the old one (and devs, etc...).

Rgds...Geoff

[Denver Osborn]

I've heard from HP about this and the short answer was to reboot to clear it up.

[Patrick Wallek]

Denver,

Off topic -- Just curious....Have you changed jobs? You used to work in the HP RC didn't you?

No points please.

[Denver Osborn]

Hey Patrick,

You're right. I left the response center Sept 2003 in favor of being a full time SysAdmin in St Louis.

-denver

[Peyman Javaheri]

Hi,

I came across this problem several months ago, and unfortunately reboot was the only option. When you recreate a lun with the same name as a previous one or resize it diskinfo will only use the cached info from the last reboot. Please update this thread if you find a way to do this without reboot.

thanks,
peyman;

[Denver Osborn]

I haven't been able to bounce the box yet and had one interesting thing to note.

1 of the 3 nodes w/ access to the same LUN doesn't have this problem. I can delete and recreate the lun as a different size and the one node sees the correct size immediatley, no ioscan or insf or reboot needed. Strange thing is that the good node was cloned from one of the problem nodes... and they're at the same patch revs. The only difference is the way the connect to the fabric.

problem nodes attach have to fc hba's, each hba is connected to a seperate fc switch. Each one of the va's controllers is also connected to each one of the switches. There's an isl between the 2 switches. The "good" node is connected via a 3rd switch that has an isl to the other 2 switches. Theses fc swaitches are brocade 2800's at f/w 2.6.2a.

Anyone have any other ideas here?

[Bob_Vance]

Interesting.
I've not had problems with this.

I just tested on 11.11 and VA7110.
Created 2.3GB LUN 501.
ioscan
insf -e
diskinfo reports 2.3GB.
Deleted the LUN.
diskinfo *reports an error*, as I would expect.
Created 4.3GB LUN 501.
diskinfo immediately reports 4.3GB
Deleted the LUN.
Created 1.3GB LUN 501.
diskinfo immediately reports 1.3GB
Deleted the LUN.
diskinfo reports an error

My systems are also dual-attached thru 2 fabrics.
No problems at all.
However, I *am* patched up to date with *all* patches.
Also, mine are VA7110's, not VA7100's.

bv

[Peyman Javaheri]

Sorry...I take my answer back. You are using VA7100. I was working on an EVA.

And I was thinking you cannot resize a 7100 lun. Because of that I was always removing the lun and recreating it with the new size, which never gave me any trouble. (whith exception of fabric login)

regards,
peyman;

[Denver Osborn]

I've managed to "break" the working node that was able to see the lun size changes w/ out any problems. I think it's a vxvm relaed problem. The other 2 nodes that had the initial problem had vxvm startup at boot, it was in use at one time but isn't anymore. So to troubleshoot, I started up vxvm processes on te working node, then did a few vxdisk commands... then removed, created the lun and this broke the box.

I've run vxdiskunsetup -C on the disks, but no change. I also tried to shutdown the vxvm stuff, all works well except I can't kill vxiod. This is probably while I'll have to bounce the box.

Anyone else have this problem w/ vxvm and lun changes?

-denver