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
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
Struggling to see value of fs_size_fixed on - I'm sure there is a reason, but in the context of snap mirror volume pairs its problematic.
Intuitively, a future rev of system manager should recognize the snap mirror relationships and allow the admin to resize both in one step to avoid the destination being too small and also the destination remaining over allocated.
thanks
On Jun 22, 2012, at 7:23 PM, Bryce Eller wrote:
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.com 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
-
Bryce Eller -
Fletcher Cocquyt