Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SF5.1 VxDMP caches LUN size?

Created: 12 Jun 2012 • Updated: 12 Jun 2012 | 8 comments
This issue has been solved. See solution.

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 :)

Comments 8 CommentsJump to latest comment

Gaurav Sangamnerkar's picture

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

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

Gaurav Sangamnerkar's picture

Link for DLE in Linux

https://sort.symantec.com/public/documents/sfha/5....

G

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

ursi's picture

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 ....

aborzenkov's picture

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.

ursi's picture

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
 

aborzenkov's picture

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.

ursi's picture

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 :)

ursi's picture

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.

SOLUTION