vgextend io error

[Chad Brindley]

Thanks Torsten.

The system was built in 2005 and the LUNS created then and presented to the Server, they have since been sitting there unused.

The device file c4t2d5 has files created in /dev/dsk/ and /dev/rdsk/ which made me think pvcreate has been run?

Am I wrong to think this?

Chad

[Torsten.]

>> The device file c4t2d5 has files created in /dev/dsk/ and /dev/rdsk/ which made me think pvcreate has been run?


No, you cannot assume this.

/dev/dsk/c4t2d5 and /dev/rdsk/c4t2d5 are the device files for this disk (LUN in this case);
pvcreate will create the LVM structure on this disk, you need to use "pvdisplay" to see them.

You cannot add a disk to a VG if there are no LVM structures on it.

[Chad Brindley]

Torsten thats fantastic, learning as we go here.

So I will need to run pvcreate so LVM knows about it otherwise the vgextend does not recognise it as a device it can use.

I was told previously with some math you can work out the LUN number from the device name
e.g. c4t2d5.

Is this correct? If so what's the algorithm? I just wanted to ensure the device is linked to the LUN I think it is.

[Manix]

Hello Chad !!

whats your other query ,related to PV size must been solved ..hope so -)).

You wrote when you were running SAM the only
error you got was due to size and nothing else!!

I think SAM would run pvcreate itself before
vgextend.

If you are doing it through command line
you need to run pvcreate first.

Regarding LUN no you need to look at the full
HW address as shown in ioscan -fnC disk.

Depends upon version and SAN topology as well to be precise.

cxtxdx --> controller ,target ,lun.

Thanks

Manix

[Torsten.]

A calculation from the device file is not possible (well, most of the times the result is right, but it is not sure at all), but you can calculate it from the hardware path.

0/3/1/0.1.4.0.0.2.5

2 in binary is 0010

5 in binary is 101 (only 3 digits here!)

so path 2.5 is 0010.101 converted to binary.


This is already your LUN number.

10101 (bin) = 15 (hex) = 21 (dec)


Your LUN number is 21.

[Chad Brindley]

Thanks Torsten,

So using that logic;

0/3/1/0.1.4.0.0.5.1 = LUN 41
0/3/1/0.1.4.0.0.4.3 = LUN 35

I have managed to extend one of the Volume groups I need to by running a pvcreate first.

Do I need to do anything for the alternate links or is this handled by LVM?

Once I have completed this task I will of course assign points accordingly as you have all been most helpful.

Chad

[Torsten.]

Your calculation is correct.


If you don't run 11.31, you need to add the alternate pathes to the VG using vgextend.

[Chad Brindley]

We are on 11.23.

So do I just run (as below).

Assuming I dont need to pvcreate?

vgextend /dev/volumegroup /dev/dsk/c6t2d5
vgextend /dev/volumegroup /dev/dsk/c9t2d5
vgextend /dev/volumegroup /dev/dsk/c11t2d5

I have attached the ioscan just to clarify.

When I ran the pvcreate on c4t2d5 I just ran it on /dev/rdsk/c4t2d5 which worked okay, again is this correct?

Apologies for so many questions, I feel I have learn't a lot with just your help on this today.

[Torsten.]

You are right, do pvcreate only once, otherwise you delete your data.

Just vgextend the other paths and check with vgdiosplay -v ...


For this VA hardware you can use the "armtopology" command to get more information.

[Chad Brindley]

Thanks, I added those alternate paths in fine.

Just trying to extend one of our other volume groups and it says Volume Group extended successfully then just appears to hang. 15 minutes later it gave the following error message;

vgcfgbackup: IO error on Physical Volume device /dev/rdsk/c4t2d7: I/O error

It has not written to /etc/lvmconf/vgdbQBW.conf as the time and date stamp are old.

vgdisplay shows it has extended the volume group.

c4t2d7 looks like it is an alternate path setup when the volume group was created.

Chad