06-12-2012 01:59 AM
I recently recrated a LUN with a different size but the same LUN ID (Linux SLES11) and when trying to initialize it as a new disk to VxVM I keeps sticking to the old size, whatever I do (I tried to destroy and reinitialize in different formats and grow many times):
# vxdisk list isar2_sas_1
Device: isar2_sas_1
public: slice=5 offset=65792 len=167700688 disk_offset=315
Multipathing information:
numpaths: 8
sdu state=disabled
sdt state=enabled
sds state=disabled
sdam state=disabled
sdan state=enabled
sdb state=enabled
sda state=disabled
sdv state=enabled
... but the main reasons seems to be DMP is somehow sticking to the old size:
# fdisk -l /dev/vx/dmp/isar2_sas_1
Disk /dev/vx/dmp/isar2_sas_1: 85.9 GB, 85899345920 bytes
255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x55074b8b
pepper:/etc/vx # fdisk -l /dev/sdt
Disk /dev/sdt: 128.8 GB, 128849018880 bytes
255 heads, 63 sectors/track, 15665 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x55074b8b
Any hints are greatly appreciated :)
Solved! Go to Solution.
06-12-2012 08:53 AM
Just while searching other stuff I stumbled upon a solution. It seems like the bug described in TechNote 128862 is not solved in SF5.1 since I tried vxdisk rm many times:
http://www.symantec.com/business/support/index?page=content&id=TECH128862
But the solution described there worked like a charm (albeit I am happy to only have 8 paths :):
# vxdisk list isar2_sas_1 | grep state | cut -d" " -f1 | xargs -t -izzz vxdmpadm exclude vxvm path=zzz
vxdmpadm exclude vxvm path=sdt
vxdmpadm exclude vxvm path=sds
vxdmpadm exclude vxvm path=sdam
vxdmpadm exclude vxvm path=sdan
vxdmpadm exclude vxvm path=sdb
vxdmpadm exclude vxvm path=sda
vxdmpadm exclude vxvm path=sdv
# vxdctl enable
# vxdmpadm include vxvm path=sdt
# vxdmpadm include vxvm path=sds
# vxdmpadm include vxvm path=sdam
# vxdmpadm include vxvm path=sdan
# vxdmpadm include vxvm path=sdb
# vxdmpadm include vxvm path=sda
# vxdmpadm include vxvm path=sdv
# vxdctl enable
# fdisk -l /dev/vx/dmp/isar2_sas_1
Disk /dev/vx/dmp/isar2_sas_1: 128.8 GB, 128849018880 bytes
255 heads, 63 sectors/track, 15665 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9b764fd2
Yuhu! And thanks for all the hints.
06-12-2012 03:27 AM
Can u clarify a bit more .... If I understand correctly, you had a lun size of xGB before, the same Lun has been resized to a bigger size ... lets say yGB & you are not able to see the new size correct ?
If this is correct, you should go with "vxdisk resize" option for veritas to understand the new lun size, this is called Dynamic Lun Expansion...
Check for Veritas Volume manager admin guide for details ..
What is the vxvm version you are using ?
G
06-12-2012 03:32 AM
Link for DLE in Linux
https://sort.symantec.com/public/documents/sfha/5.1sp1/linux/productguides/html/vxvm_admin/ch03s16.htm
G
06-12-2012 05:22 AM
Hi Gaurav,
thanks for your fast comment! Ok, to be more presize:
1. I had an unused LUN #12 which was too small. The crappy flaky storage (Promise VTrak 610fD) does not support DLE, so I deleted the LUN, created a bigger one and mapped it out via the same LUN ID.
2. VxVM is SF 5.1 SP1 RP2 P2 (should be the most recent one for SLES11 in that series since I just patched that up)
3. Of course I tried that DLE stuff -- nothing happend because VxVM doesn't recognize the LUN is bigger
Currently I assume maybe it helps removing all references to this disk (DMP Nodes, info files) and do a 'vxdctl initdmp') but since this is a preproduction server I am a little bit anxious about destroying stuff that currently perfectly works.
Maybe I just change the LUN ID and disk name ....
06-12-2012 06:41 AM
Can you see real capacity using sg_readcap?
# sg_readcap /dev/sdX
You can try deleting SCSI device on Linux and rescanning.
Check for SCSI host adapter number:
# lsscsi ... [0:1:2:0] disk LSILOGIC Logical Volume 3000 /dev/sda
Here the first number before colon is host adapter.
Now delete SCSI device for your disk(s) for this LUN
# echo 1 > /sys/block/sda/device/delete
Verify that disk is no more visible in lsscsi output and rescan
# echo '- - -' > /sys/class/scsi_host/host0/scan
Were hostN - is the number form the first step.
Notice that sdX names will change after that. So you will need to rescan in VxVM as well. It makes sense to try to remove disk from VxVM control first.
06-12-2012 07:16 AM
unfortunately yes, as you can see above in the fdisk output, so from the OS side everything is fine:
# sg_readcap /dev/sdt
Read Capacity results:
Last logical block address=251658239 (0xeffffff), Number of blocks=251658240
Logical block length=512 bytes
Hence:
Device size: 128849018880 bytes, 122880.0 MiB, 128.85 GB
06-12-2012 07:24 AM
from the OS side everything is fine
sg_readcap goes directly to device using pass through. So it confirms that you have LUN with correct size mapped, but still OS may cache old size. In my experience such changes really require deleting old device and rescanning.
06-12-2012 08:00 AM
I know. As you can see above in my original post the OS is quite fine and uses 120GB, only DMP is sticking to those 80GB it had before. I can use the disk in the OS without any problems. Sorry :)
06-12-2012 08:53 AM
Just while searching other stuff I stumbled upon a solution. It seems like the bug described in TechNote 128862 is not solved in SF5.1 since I tried vxdisk rm many times:
http://www.symantec.com/business/support/index?page=content&id=TECH128862
But the solution described there worked like a charm (albeit I am happy to only have 8 paths :):
# vxdisk list isar2_sas_1 | grep state | cut -d" " -f1 | xargs -t -izzz vxdmpadm exclude vxvm path=zzz
vxdmpadm exclude vxvm path=sdt
vxdmpadm exclude vxvm path=sds
vxdmpadm exclude vxvm path=sdam
vxdmpadm exclude vxvm path=sdan
vxdmpadm exclude vxvm path=sdb
vxdmpadm exclude vxvm path=sda
vxdmpadm exclude vxvm path=sdv
# vxdctl enable
# vxdmpadm include vxvm path=sdt
# vxdmpadm include vxvm path=sds
# vxdmpadm include vxvm path=sdam
# vxdmpadm include vxvm path=sdan
# vxdmpadm include vxvm path=sdb
# vxdmpadm include vxvm path=sda
# vxdmpadm include vxvm path=sdv
# vxdctl enable
# fdisk -l /dev/vx/dmp/isar2_sas_1
Disk /dev/vx/dmp/isar2_sas_1: 128.8 GB, 128849018880 bytes
255 heads, 63 sectors/track, 15665 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9b764fd2
Yuhu! And thanks for all the hints.