We were getting close to running out of space on one of our database volumes last week, and I needed to add some additional storage to ensure that things kept running smoothly. The admin who originally created the VxVM database volume only used half of each of the five disks that were associated with the volume / file system that were at capacity, which meant I had roughly 18GB of free space available on each device to work with:
$ vxdg free | egrep '(D01|D02|D03|D04|D05)'
GROUP DISK DEVICE TAG OFFSET LENGTH FLAGS datadg D01 c2t0d0s2 c2t0d0 35547981 35547981 - datadg D02 c2t1d0s2 c2t1d0 35547981 35547981 - datadg D03 c2t2d0s2 c2t2d0 35547981 35547981 - datadg D04 c2t3d0s2 c2t3d0 35547981 35547981 - datadg D05 c2t4d0s2 c2t4d0 35547981 35547981 - datadg D06 c2t5d0s2 c2t5d0 35547981 35547981 -
Now there are a number of ways to resize volumes and file systems with VxVM and VxFS. You can use vxassist to grow or shrink a volume, and then use the fsadm utility to extend the file system. You can also perform both of these operations with vxresize, which takes the name of the volume to resize, the disk group the volume is a part of, and a size parameter to indicate that you want to grow (you use a “+” to indicate that you want to grow the volume by the value immediately following the plus sign) or shrink (you use a “-” to indicate that you want to shrink the volume by the value immediately following the dash) the volume. Since I preferred the most efficient method to resize my volume, I fired up vxresize and told it to extend the volume named datavol01 by 35547981 blocks:
$ /etc/vx/bin/vxresize -g datadg -F vxfs datavol01 +35547981
Instead of specifying blocks, you can also use unit specifiers such as “m” to denote megabytes, and “g” to denote gigabytes. As with all operations that change the structure of storage, you should test any resizing operations on non-production systems prior to changing production systems.