ONTAP Hardware

## Help: Understanding Volume available space

6,969 Views

Hey guys,

I have a question about available space on NetApp FAS system.

Here the givens:

Volume - 400GB / Flexible / 10% Snapshot reserve

One LUN in this Volume - 150,0021GB / Space Reserved

So my calculation is:

400GB - 150GB - 150GB (first Snapshot) - 40GB = 60GB available

two questions:

-there is more than one snapshot available... how is it possible, that my volume available storage shows: 77,5GB?

-Snapshots are stored in normal data space... when data space is full, they will use the snapshot reserve... right?

regards!

12 REPLIES 12
6,876 Views

Data will never live in snapshot space

Snapshots however can live in data space

6,876 Views

OK, thanks for your fast response.

that means, that I'm right, saying, that for snapshots the data space is used and when data space is full snapshots will use their reserved space?

regards

6,876 Views

If you set snapreserve then snapshots will live there. Once your snapshots

take up all the reserve, they either rotate off or fail, depending on your

setup

6,876 Views

Sorry, but that’s completely wrong. Snap reserve never limited how much space snapshots can consume.

You can set policy to delete snapshots if snapreseve gets full (which is not default) but it will never cause snapshots to fail.

6,876 Views

You're correct.

However if the data side is full and your snap reserve is full then it

might happen.

6,876 Views

Thats my thoughts to... I need to know... Is my calculation right? (see first post)

it's based on the thoughts, that snapshots use the dataspace and when it's full they will use the snapshot reserved space... can you please take a look on my calculation?

thanks

regards

6,876 Views

Err, not exactly.

Snap reserve space will show used for changed blocks as data in the LUN is overwritten after taking a snapshot.

Fractional reserve is another mechanism for reserving space in a volume for overwriting blocks in a LUN which has had a snapshot taken.

Snap reserve is usualy set to zero for volumes containing a LUN, given that we have Fractional reserve to use to guarantee overwrites.

See the 'Storage Provisioning' section of the 'Block Access Management Guide'.

There's also an excellent TR on thin provisioning in a SAN environment:

http://media.netapp.com/documents/tr-3483.pdf

You may also wish to look at tr3563.

I hope this response has been helpful to you.

Eugene E. Kashpureff
ekashp@kashpureff.org
Fastlane NetApp Instructor and Independent Consultant

6,876 Views

OK, thanks... I got this...

but  is my calculation in the first post right? How is it possible to have  more free space than calculated... with more than one snapshot??? (I  calculated with one snapshot)

Please take a look at it...

Thanks!

regards

6,876 Views

Your calculation in the first post is close, but the LUN wasn't full of data.

The LUN cost you  150G, but the first snap only took ~133G more, 'cause you

only had that much data written to the LUN. Additional snapshots would only

take up the delta ammount of space.

With fractional reserve at 100% ONTAP guaranteed space to write 150G more.

I hope this response has been helpful to you.

Eugene E. Kashpureff
ekashp@kashpureff.org
Fastlane NetApp Instructor and Independent Consultant

6,455 Views

Oh of course... the LUN File has a size of 150GB, but the NetApp filer knows wich blocks are written.. so the snapshot will only take the written blocks...

I should take the exactly LUN size for my calculation...

thanks!

6,455 Views

I actually like SAN volumes to be thin and hold a snap reserve to monitor the level of snap capacity usage against: the thin provisioned vol will always leave some additonal capacity while having a snap reserve will allow a level of automation to curtain unwanted snap growth.

just my 2 cents.

6,455 Views

Joost -

That thin provisioning will work out to a lot more than two cents worth of storage !

This could be a very valuable comment to any who are not thin provisioning...

I hope this response has been helpful to you.