fs_size_fixed option

[rbauman79]

i have a snapmirror relationship that was not working. We determined we changed the source vol size but not the destination size (duh). so i did the following:

Step 1 — Temporarily break the mirror to make the volume read/writeable
site2>snapmirror break demo4
Step 2 — Change the volume option of our “demo4″ volume fs_size_fixed to off
site2> vol options demo4 fs_size_fixed off
Step 3 — Increase the size of the destination volume
site2> vol size demo4 +1100g
Step 4 — Change the fs_size_fixed back to on before we resume the mirror
site2> vol options demo4 fs_size_fixed on
Step 5 — Re-establish the mirror
site2>snapmirror resync -S sourcefiler:sourcevolume destinationfiler:destinationvolume

Now the snapmirror has resumed the transfer which is good, but i see on the putty session of the destination when i do a df -h the total size is still set to 3061gb which was the old amount before i added space.  i know the fs_size_fixed syncs that information between source & destination so they are identical. my source vol size is: 4085GB.

When does the destination sync up the total size to match the source? Is it after it completes the resync transfer or should it be instantaneous? The space was showing correctly on the destination before i issued the vol options demo4 fs_size_fixed on command.

thanks

[billshaffer]

df shows the size of the filesystem, which is almost always the size of the volume.  The only exception I can think of is in a scenario like this - because the filesystem is mirrored, the size of the source filesystem is used, regardless of the size of the volume.  I would expect the df output to change once the relationship is back in a snapmirrored state.

A few notes on your process - in older version  on ONTAP (can't remember how long ago, but a while), you had to break the snapmirror relationship before you could grow the destination volume, but that is no longer the case.  And you never had to change the fs_size_fixed option for this.  In current versions, if you grow the destination volume while the relationship is still in a snapmirrored state, you get a warning saying something to the effect that the source filesystem size will be used - but it still grows the volume.  On the next update, the filesystem size should be set to whatever the source is.

Bill

[JGPSHNTAP]

is the dst thin provisioned?

Show us vol size from both controllers

[rbauman79]

I am currently running 8.1.1RC1 (Upgrade to latest version  is on the project books, just not ready to do it yet until I finish other projects).  Do you remember when that changed?  I guess initially I tried doing the dest volume size change using the GUI but noticed the size was in increasing. I didn't do it via the cli because I read other people say how to grow the dest. Is 8.1.1RC1 on that list or do I need to upgrade in order to advantage of that resizing feature.

JGPSHNTAP

is there a command that shows me if it is thin provisioned? In the GUI if I click edit it tells me snapmirror destination volume cannot be edited.

I tried vol status <vol name> but didn't see anything in there about thin provisioning.  I am pretty sure it is thin provisioned but want to confirm.

Source: vol size: Flexible volume  'VMware_OS' has size 4284229880k

Destination: vol size Flexible volume 'VMware_OS' has size 43663921656k

[billshaffer]

I can't remember when they made the change, but I'm pretty sure it was pre-8.1.  Easy way to test - try resizing one of your destination volumes.  If it lets you, but leaves the filesystem the same (seen from df) then you're golden....

Bill

[JGPSHNTAP]

Vol options will show you if guarantee is set to none

Also, why are you running RC code for production Vmware?  Bad idea.

Also, 8.1.1 is very old.. Time to upgrade my friends.. Lots of bug fixes.. All upgrades are NDU and take maybe 1hr, with no downtime.  I would highly recommend doing this.

[rbauman79]

I know I need to update to the latest version, thank you for being gentle... I am overworked with other projects and have not been able to get to it.  Initially this was just a NAS box running CIFS, but then we tacked on Virtualization to the box a year ago.  We had the 2240ha installed by a netapp engineer. I am surprised he did not upgrade it but then again that was 3 years ago so maybe that was the latest version back then. I can't remember.

[billshaffer]

Hell, 8.1.1 is nothing.  I still run a 7.3 cluster....

[JGPSHNTAP]

7.3.7 is solid.. But 8.2.x or 8.1.4 is better choice.. Plus he's on RC code.

You are thick provisioned