Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Netapp: toasters

shrinking snap mirror destination volume size does not return space

 

 

Netapp toasters RSS feed   Index | Next | Previous | View Threaded


fcocquyt at stanford

Jun 22, 2012, 9:26 AM

Post #1 of 3 (594 views)
Permalink
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 at trace3

Jun 22, 2012, 7:23 PM

Post #2 of 3 (553 views)
Permalink
RE: shrinking snap mirror destination volume size does not return space [In reply to]

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 [at] trace3<mailto:bryce [at] trace3>
www.trace3.com<http://www.trace3.com/>

From: toasters-bounces [at] teaparty [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
Sent: Friday, June 22, 2012 9:26 AM
To: toasters [at] teaparty 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


fcocquyt at stanford

Jun 22, 2012, 8:12 PM

Post #3 of 3 (552 views)
Permalink
Re: shrinking snap mirror destination volume size does not return space [In reply to]

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 [at] trace3
> www.trace3.com
>
> From: toasters-bounces [at] teaparty [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
> Sent: Friday, June 22, 2012 9:26 AM
> To: toasters [at] teaparty 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
>

Netapp toasters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.