Unable to grow or resize Veritas Volume or VxFS File System even when "vxassist maxsize" shows free space

book

Article ID: 100053626

calendar_today

Updated On:

Description

Error Message


Sample error messages:

# vxassist -g dg1 maxsize
Maximum volume size: 51587072 (50378Mb)

# vxresize -g dg1 vol1 +5G
VxVM vxassist ERROR V-5-1-436 Cannot allocate space to grow volume to 5754880 blocks
VxVM vxresize ERROR V-5-1-4703 Problem running vxassist command for volume vol1, in diskgroup dg1

# vxassist -g dg1 maxgrow vol1
Volume vol1 can be extended by 75776 to: 587776 (574Mb)

Cause

Most common and probable causes are outlined below:
 

1. The Disk Group contains sites for site consistent and is missing required VxVM site tags for the newly added disks.
 

2. The volume is either striped or mirrored.


3. The volume was prepared with the vxsnap command and has DCO (Data Change Object) log associated with it, the maxsize calculation fails to consider the DCO object size when attempting to grow or resize the Veritas Volume & VxFS File System.

 

Resolution

Scenario #1
 

1. The disks involved are site consistent and the newly added disks are missing the required VxVM site tags.


Example:

The disk group "dg1" contains a volume named "vol1"

# vxprint -htg dg1 vol1
v  vol1 -      ENABLED  ACTIVE   512000   SELECT    -        fsgen
pl vol1-01 vol1 ENABLED ACTIVE 512000 CONCAT - RW
sd vol1-02 vol1-01 emc0_10 10485760 512000 0 c34t0d1 ENA

 

Check for site tags.
 

# vxdisk -v list c34t0d1
Device:    c34t0d1
devicetag: c34t0d1
type:      auto
hostid:    testserver
disk:      name=emc0_10 id=1193308916.30.testserver
timeout:   60
pftostate: enabled
group:     name=dg1 id=1208981232.57.testserver
info:      format=cdsdisk,privoffset=128
flags:     online ready private autoconfig noautoimport imported clone_disk thinrclm
pubpaths:  block=/dev/vx/dmp/c34t0d1 char=/dev/vx/rdmp/c34t0d1
guid:      {e802cfbc-1dd1-11b2-8f4f-0017a4a47464}
udid:      HITACHI%5FOPEN-V%5F0D9A9%5F719A
site:      testsite                 >>>>>>>>>>>>> Here the existing disk has a site Tag
version:   3.1
iosize:    min=512 (bytes) max=2048 (blocks)
public:    slice=0 offset=1152 len=15351168 disk_offset=0
private:   slice=0 offset=128 len=1024 disk_offset=0
update:    time=1659403342 seqno=0.352
ssb:       actual_seqno=0.0
headers:   0 120
configs:   count=1 len=640
logs:      count=1 len=96
Defined regions:
 config   priv 000024-000119[000096]: copy=01 offset=000000 enabled
 config   priv 000128-000671[000544]: copy=01 offset=000096 enabled
 log      priv 000672-000767[000096]: copy=01 offset=000000 enabled
 lockrgn  priv 000768-000839[000072]: part=00 offset=000000
Annotations:
 tag      udid_asl=HITACHI%5FOPEN-V%5F0D9A9%5F719A
 tag      site=testsite
Multipathing information:
numpaths:   2
c34t0d1         state=enabled
c35t0d1         state=enabled



The existing disk "c34t0d1" has an existing site tag defined as "testsite

VxVM site tags for a specific disk group "dg1" can be shown as follows:

# vxdisk -g dg1 listtag
DEVICE          NAME                            VALUE
c34t0d1         site                            testsite

c34t0d5         site                            testsite
c34t1d3         site                            testsite

The disk group "dg1" consists of more disks than what is shown above:

# vxdisk list | grep dg1
c32t0d5      auto:cdsdisk    emc0_1  dg1 online thinrclm
c32t0d6      auto:cdsdisk    emc0_2  dg1 online thinrclm
c32t1d0      auto:cdsdisk    emc0_3  dg1 online thinrclm
c32t4d5      auto:cdsdisk    emc0_4  dg1 online thinrclm
c32t6d1      auto:cdsdisk    emc0_5  dg1 online thinrclm
c32t14d6     auto:cdsdisk    emc0_6  dg1 online thinrclm
c32t14d7     auto:cdsdisk    emc0_7  dg1 online thinrclm
c32t15d1     auto:cdsdisk    emc0_8  dg1 online thinrclm
c32t15d3     auto:cdsdisk    emc0_9  dg1 online thinrclm
c32t15d4     auto:cdsdisk    emc0_12  dg1 online thinrclm
c32t15d5     auto:cdsdisk    emc0_11  dg1 online thinrclm
c34t0d1      auto:cdsdisk    emc0_10  dg1 online thinrclm
c34t0d5      auto:cdsdisk    emc0_13  dg1 online thinrclm
c34t1d3      auto:cdsdisk    emc0_14  dg1 online thinrclm
c34t1d6      auto:cdsdisk    emc0_15 dg1 online thinrclm

 

Conclusion, the newly added disks do not have a VxVM site tag associated with them


In this instance, define the VxVM site tag as "testsite" for all required disks in disk group "dg1":


# vxdisk -g dg1 settag testsite c32t0d5 c32t0d6 c32t1d0 c32t4d5 c32t6d1 c32t14d6 c32t14d7 c32t15d1 c32t15d3 c32t15d4 c32t15d5 


All disks associated with disk group "dg1" now all have a VxVM site tag of "testsite":

# vxdisk -g dg1 listtag
DEVICE          NAME                            VALUE
c32t0d5          site                            testsite

c32t0d6          site                            testsite
c32t1d0          site                            testsite
c32t4d5          site                            testsite
c32t6d1          site                            testsite
c32t14d6         site                            testsite
c32t14d7         site                            testsite
c32t15d1         site                            testsite
c32t15d3         site                            testsite
c32t15d4         site                            testsite
c32t15d5         site                            testsite
c34t0d1          site                            testsite
c34t0d5          site                            testsite
c34t1d3          site                            testsite
c34t1d6          site                            testsite


Now all the newly added disks have been tagged with the site tag "testsite", the vxresize operation completes as designed.

# vxresize -g dg1 vol1 +5G      

 

Scenario #2
 

2. If the volume is either striped or mirrored


Perform the vxassist operation with additional layout attributes, depending on the required configuration layout:

In the case of a stripe volume with 2 columns, try:

# vxassist -g dg1 maxsize layout=stripe ncol=2   


In the case of a mirrored volume, try:  

# vxassist -g dg1 maxsize layout=mirror  

 

Scenario #3
 

3. The volume was prepared with the vxsnap command and has DCO (Data Change Object) log associated with it, the maxsize calculation fails to consider the DCO object size when attempting to grow or resize the Veritas Volume & VxFS File System.
 

Check the "vxprint -ht" output for any DCO logs which is assigned to the volume and add more disks if required.

 

Issue/Introduction


The Veritas Volume Manager (VxVM) command "vxassist maxsize" shows space available for a Disk Group, but "vxassist maxgrow" shows a different size.

The user is unable to grow or resize a specific Veritas Volume or VxFS File System.