Run "vol options volname fs_size_fixed off" on the destination volume and you will then be able to shrink it.
-- Bryce Eller Solutions Architect Trace3
818-264-8310 (m) 949-333-1812 (f) bryce@trace3.commailto:bryce@trace3.com www.trace3.comhttp://www.trace3.com/
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt Sent: Friday, June 22, 2012 9:26 AM To: toasters@teaparty.net Lists Subject: shrinking snap mirror destination volume size does not return space
I'm teaching our storage team to use the System Manager to resize volumes (both source and destination snap mirror volumes)
Then one team member noticed this old issue - when the SM src/dest pair volumes are shrunk - the new size is not reflected on the destination - even after a SM update.
Last year I wrote about this http://www.vmadmin.info/2011/04/shrinking-snapmirror-destination.html
and the solution at the time was to break the SM to have the destination space reclaimed.
But is there a better method?
This script shows I have volumes with space reclaimable:
ssh na01 -l root vol status -b | awk '{print $0" diff = "($3-$4)*4096/1024/1024" gb"}' Volume Block Size (bytes) Vol Size (blocks) FS Size (blocks) ------ ------------------ ------------------ ---------------- vol0 4096 78643200 78643200 diff = 0 gb pweb 4096 249036800 249036800 diff = 0 gb vm64 4096 810675078 805306368 diff = 20971.5 gb eweb2 4096 13369344 13107200 diff = 1024 gb sbackup2 4096 311951361 308543488 diff = 13312 gb vds 4096 191365120 180879360 diff = 40960 gb svm2 4096 563714458 563714458 diff = 0 gb sarchive 4096 562141594 549034394 diff = 51200 gb svm4 4096 629145600 603979776 diff = 98304 gb vb2 4096 2883584 2685440 diff = 774 gb cldb 4096 1184890880 1184104448 diff = 3072 gb cl2 4096 1848377344 939524096 diff = 3550208 gb
thanks