diskinfo doesn't return new size

[Eric SAUBIGNAC]

Bonsoir,


Online JFS : every thing should go well to increase the size of a mounted filesystem. Yes, but ...

For some reasons the filesystem itself is mounted directly from a disk special file, not from an LVM structure. When the size of the corresponding LUN is increased, diskinfo doesn't return the new size until the disk special file is released. That is if I want to deal with the new size, I must unmount the FS before. In other words I can't extend the FS size online ... :-(

It is not a problem with LVM, nor Online JFS : vmunix doesn't return new sizes as long as the correspondig resource is in use. For example, a simple "sleep 3600
Tried many ioscan, rmsf, insf, etc ... no way.

I have an idea about your answers :-( , but I wonder if it could be possible to bypass this behavior : a kernel parameter, a patch, some hidden or missunderstood parameters to commands, features from VxVM, or VxFS, that could release a FS a few sec without unmounting, etc ... ????

I forgot : no way to use the new IO stack from 11iv3 ... OS is 11iv2 and can't be upgraded soon.

Thanks in advance.


Eric

[Torsten.]

Some time ago I played around with vgmodify in 11.23:

# saconfig /dev/ciss3 -E 1 -c 100
Logical drive 1 extended from 87.9 GB to 100 GB in capacity

# diskinfo -v /dev/rdsk/c3t0d1
SCSI describe of /dev/rdsk/c3t0d1:
vendor: HP
product id: LOGICAL VOLUME
type: direct access
size: 92159040 Kbytes
...

(not changed)

# umount /user1
# vgchange -a n vg01
# vgmodify -o vg01
# vgchange -a y vg01

# diskinfo -v /dev/rdsk/c3t0d1
SCSI describe of /dev/rdsk/c3t0d1:
vendor: HP
product id: LOGICAL VOLUME
type: direct access
size: 104857600 Kbytes
...

This is what I did. Not sure if vgmodify and diskinfo is related anyhow, but maybe my "umount" did it.

[TTr]

I had the same issue. I even rebooted the server but ioscan does not see the new size. What I did not try and I suggest is to remove the mapping for that LUN (unmask or unpresent), run ioscan on the server without the LUN and then remap the LUN to the server as if it is a new disk.

[TTr]

Eric,

I misunderstood your question in my previous reply. I guess "extendfs" is only LVM aware and not physical disk aware.

[Eric SAUBIGNAC]

Bonjour,


Torsten, in your example I think IMHO that vgmodify and diskinfo are not related : diskinfo would have returned the right size just after "vgchange -a n vg01". I did this test yesterday before posting : 1 Go LUN created on EVA, ..., vgcreate, vgchange -a y, increase LUN to 2 Go, diskinfo wrong, vgchange -a n, diskinfo ok.

TTr, my problem is not related to lvm, extendfs, fsadm.

The problem is that I can't extend a FS online, though OnlineJFS is installed, if this FS resides on a raw device. I have to unmount the FS so that diskinfo shows the new size. After that I can "extendfs" before mounting, or mounting then "fsadm -b newsize".

OnlineJFS works well, the fact is that vmunix (diskinfo) doesn't return new sizes as long as the corresponding resource is in use. OnlineJFS has no sense if I have to unmount a FS to get the new size :-(

I can't believe it. Even under Windows, extending a LUN size works : new space is accessible at once after a disk scan ! Of course extending the FS is an other story.

Any idea ? Patch, kernel parameters, unknown command, ... ? Asking HP for modifying this behavior ;-) ?

Eric

[Duncan Edmonstone]

Eric,

What happens if you try using the 'remount' option on a mount command:

mount -o remount /dev/dsk/c0t0d0 /myfs

Does it pick up the change in size then?

HTH

Duncan

[Duncan Edmonstone]

I should have indicated - you can run the remount command even with files open on the filesystem...

HTH

Duncan

[Eric SAUBIGNAC]

Duncan,

I tried this option yesterday, but it was not the good way :-(

Eric

[psreedhar]

I will check with the owner of the diskinfo command/SCSI services and let you the solution.

[Eric SAUBIGNAC]

There is no problem with the owner of "diskinfo". It works perfectly but the problem described before.

Eric

[Torsten.]

In my understanding psreedhar wants to talk to the code developers ...

[Eric SAUBIGNAC]

Well, well, well ... I must apologize psreedhar : I understood you had suggested that there might be a problem with file mode access permissions (owner ...) In my discharge, I have to say that I was very in a hurry yesterday morning. But in fact, I really still need to improve my english ;-)

If you can join code developers, post something : it will be my pleasure to correct points assignment I did.

Torsten, many, many thanks for your remark. Do it again every time you will consider it necessary !

Eric

[psreedhar]

Hi,
I spoke to SCSI Developers,
They told, you have to close all the open devices and then reopen it get the new size reflected.
So mount open the Disk and keep it open until we unmount it.
Only during open time the size is queried.

This problem is solved in 11.31 because of Mass storage stack.

[Eric SAUBIGNAC]

Bonjour psreedhar ... & everybody there,

"They told, you have to close all the open devices and then reopen it get the new size reflected" ... it is exactly what I have underlined in my initial post. It is badly true at any level. A call at HP support has confirmed this : as long as "open count > 0", SCSI inqueries are directed to a cache.

"This problem is solved in 11.31 because of Mass storage stack" ... yep, but I can't relie on HP-UX 11.31 as few of my clients are working with this release.

I would like to explain in which context I need that new disk size is immediatly acknowledged : Integrity VM.

For some reasons (IMHO valuables reasons ;-) I work with LV as virtual disks at host level and FS straight on virtual LV disks in VM Guests; main reasons are performances and portability. I know that I should consider HPVM 3.5 for performances, but how do you deal with portability ? I mean if you have a double LVM layer, one at host level, one at guest level, and if you want to move from V2P (virtual to physical) or P2V, then you must copy all of the datas. You can't simply play with disks ...

In a summary, with LVM layer at host level and FS layer at guest level, I thought I would be able to online extend FS with OnlineJFS. It could work ... without this f.....g "Only_during_open_time_the_size_is_queried" behavior.

I can imagine that a patch could permit to modify this behavior, through a kernel parameter or through a special command that will update SCSI cache when invoked. It could be limited to VM Guests and I am sure it would be a valuable enhancement in VM context. It could, it could, ... Yep, but does someone there know how to ask HP such a modification ? psreedhar, should I understand that you can join HP development team ?

Eric

[Dennis Handly]

>but does someone there know how to ask HP such a modification?

If you have a support contract, contact the Response Center and file an enhancement request.

[Eric SAUBIGNAC]

Thanks Dennis.

I have already asked HP support engineer in charge of the opened case to forward my demand. But really, I have a doubt it can succeed ... Since you are working for HP, what do you think about it ?

Eric

[Dennis Handly]

>I have already asked HP support engineer in charge of the opened case to forward my demand.

Did you get any numbers for your enhancement request?

>Since you are working for HP, what do you think about it?

Well, if it isn't for 11.31, it probably won't. And since it works on 11.31, catch 22.

What's the cost to your clients, you and HP if this isn't working the way you want?

[Eric SAUBIGNAC]

Here is an extract of HP's L3 support :

-----------------------------------------
The caching of LUN data is done for performance reasons and there are no plans to change that. The reason is that it's not enough just not to cache the size of LUN in order to achieve dynamic expansion.

The dynamic LUN expansion is feature of Next Generation mass storage stack on 11.31.See for example: http://docs.hp.com/en/MassStorageStack/The_Next_Generation_Mass_Storage_Stack.pdf

The dynamic LUN expansion on 11.31 goes beyond simply allowing dynamic changes and supports also notification of upper layers which allows for example crash dump or LVM to automatically react to the LUN changes.

In case of HPVM things are even more complicated. As of today there is no infrastructure in place to allow propagation of LUN changes to the guest OS so the only way to reread the LUN configuration is the reopen the device (which means unmounting the FS on guest in case of FS on raw device).

There are some changes in plan for AVIO Storage drivers on future HPVM version(s) which will be 11.31 host based to subscribe to LUN/LVOL resize events and propagate these.

But that's future functionality which we cannot give any promises about.

So from the HPUX point of view the functionality customer ask for is there in 11.31 but not in 11.23 and there are no plans to change that.

For HPVM there are plans to allow dynamic resizing in future versions.
-----------------------------------------

So no solution ... but making a choice between uncomplete solutions. An other point for HP's competitors :-(

Thanks every body

Eric