VxVM Shrink a volume online

regarding the previous issue with resizing the 500g volume:

although it's not possible to say with certainty why it may have failed without knowing the exact details/output from the time you encountered, possible causes of resize problems/failure (in addition to Gaurav's earlier points) include:

a. the filesystem is being heavily used while resize is being run (ideally should quiesce the filesystem whilst the resize operation is in progress) - so retry the resize during a quieter period

b. the filesystem is fragmented - defragment the filesystem and retry the resize.

technote: http://www.symantec.com/business/support/index?page=content&id=TECH72741

see VxFS 5.1 (Linux) Adminstrator's Guide -> VxFS performance: creating, mounting, and tuning file systems -> Monitoring free space -> Monitoring fragmentation

https://sort.symantec.com/public/documents/sf/5.1/linux/html/vxfs_admin/ch02s04s01.htm

regarding the current filesystem:

From the output there appears to be sufficient filesystem & diskgroup space. You can migrate to the hds_65133* disks after the resize is done (as it currently doesn't reside on these disks).

Could you provide the following output to confirm the vxfs version /details?

# fstyp -v /dev/vx/rdsk/cnups1ds_dg1/cnups1ds_oraclepss

If the filesystem is vxfs, you should be able to resize the fs using the steps below (confirm with fstyp first).

1. Verify the filesystem is not fragmented

2. Run vxresize (preferably not during a period of heavy use), eg: to shrink to 200g

# vxresize -s -F vxfs -g cnups1ds_dg1 cnups1ds_oraclepss 200g
(note the filesystem must be mounted to perform the resize. see vxresize manpage for more info: https://sort.symantec.com/public/documents/sf/5.1/linux/manpages/volume_manager/man/html/man1m/vxresize.1m.html )

3. Verify the filesystem and volume have shrunk:

# df -h /oracle/PSS
# fstyp -v /dev/vx/rdsk/cnups1ds_dg1/cnups1ds_oraclepss
# vxprint -qhtrg cnups1ds_dg1 cnups1ds_oraclepss

4. Once the filesystem has been resized, you can migrate to the hds_65133 disks by mirroring with vxassist, then removing the original emc_4798 plex.

eg: to mirror to disk hds_65133_0143 (~500gb free from your output, so should have sufficient space once fs shrunk to 200g - substitute with desired disk(s) if you wish to use a different device)

# vxassist -b -g cnups1ds_dg1 mirror cnups1ds_oraclepss hds_65133_0143
######## (-b runs in background, check progress with vxtask list)

Check the mirror operation is complete, both plexes ENABLED and ACTIVE

# vxtask list #### should return no output
# vxprint -qhtrg cnups1ds_dg1 cnups1ds_oraclepss

remove the mirror on emc_4798

# vxassist -g cnups1ds_dg1 remove mirror cnups1ds_oraclepss !emc_4798_0eba
#### NOTE: this assumes the original plex is on emc_4798_0eba, which should be the case from the output you've provided. if vxprint shows a different device, substitute the correct disk in the remove mirror command above

see vxassist manpage for more details: https://sort.symantec.com/public/documents/sf/5.1/linux/manpages/volume_manager/man/html/man1m/vxassist.1m.html

If you encounter any issues, please provide the exact command(s) run and the error output to investigate further.

Alternatively you could also try the resizing the filesystem separately per ScottK's suggestion (resize fs with fsadm first, then resize the volume with vxassist) - you do need to take care re: the order and correct sizing as he's mentioned above.