lun and vol size

TDUBB1234 · ‎2012-07-09

aggr show_space -h

vol1 661GB 659GB none

------------------------------------------------------------------------------------

df -V -h

vol1 661GB 659GB none

----------------------------------------------------------------------------------

lun show -v

/vol/vol1/lun1 400.1g

why is my vol1 not the same as my lun1?

ivisinfo · ‎2012-07-10

Probably your LUN is "thin provisioned", i.e. it is actually empty from the host side.

As the host fills up this disk/LUN it will start gaining size in the volume. You can enable the LUN reservation option.

See here: http://www.netapp.com/us/communities/tech-ontap/tot-btb-thin-provisioning-1010-hk.html

TDUBB1234 · ‎2012-07-10

yes it is and its growing like crazy. its filling up pretty fast on the host side.

aggr show_space -h

vol1 691GB 688GB none

--------------------------------------------------------------------------

df -V -h

/vol/vol1/ 448GB 384GB 63GB 86% /vol/vol1

/vol/vol1/.snapshot 298GB 332GB 0GB 111% /vol/vol1/.snapshot

not sure why the snapshot is using so much. not sure if I can delete the snapshots.

-------------------------------------------------------------------------

lun show -v

/vol/vol1/lun1 400.1g (429557022720) (r/w, online, mapped)

Comment: ""

Serial#: dfkoFJhJAp6D

Share: none

Space Reservation: disabled

Multiprotocol Type: windows_2008

Occupied Size: 351.3g (377174339584)

Creation Time: Thu Dec 29 14:51:31 PST 2011

Cluster Shared Volume Information: 0x0

---------------------------------------------------------

snap reserve

Volume vol1: current snapshot reserve is 40% or 313520000 k-bytes

---------------------------------------------------------------

vol options vol1

nosnap=on, nosnapdir=off, minra=off, no_atime_update=off, nvfail=off,

ignore_inconsistent=off, snapmirrored=off, create_ucode=on,

convert_ucode=on, maxdirsize=45875, schedsnapname=ordinal,

fs_size_fixed=off, compression=off, guarantee=none, svo_enable=off,

svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off, no_i2p=on,

fractional_reserve=0, extent=off, try_first=volume_grow,

read_realloc=off, snapshot_clone_dependency=on, nbu_archival_snap=off

aborzenkov · ‎2012-07-10

not sure why the snapshot is using so much

This is the amount of data changed on a LUN since snapshot has been taken. It looks like LUN was almost completely rewritten since snapshot had been taken. As example, restoring full backup would have this effect.

not sure if I can delete the snapshots.

Well ... it is up to you of course. But you are rsking running out of space on this volume which will result in LUN going offline. You should either plan to increase volume size or celan up unused snapshots and reconsider snapshot policy.

ivisinfo · ‎2012-07-10

That explains your problem!

The LUN reservation is important, not the volume reservation. In the lun show you have:

Space Reservation: disabled

This means that the LUN appears as 400gb to the host, but in the volume it actually occupies only the data written from the host. When you created the LUN it occupied zero space, and as the host started writting data in it, it started occupying space in the volume. But the volume already had snapshots, and there was not 400gb free. Eventually as the host writed data, the LUN grew so much that the volume became full.

In the volume you already have 332gb of snapshots. If the LUN gets full, the total space you would have is 332+400=732gb. That's above your volume size and explains why it get filled up.

You can try to enable the lun reservation, but the system will not let you do it because now you do not have enough space in the volume because of the snapshots.

At this point you must start fresh and bring the volume to a balance.

1. if you can, delete your snapshots. "Can" means that they are not needed for some reason. If for example you have snapmirror or snapvault, the you cannot delete them, because some of them are needed for the mirror or snapvault. Do a snap list and identify your snapshots. If you have deleted all your snapshots, then the volume will have only the LUN in it. Bring the LUN online and use it normally from the host. If you want to have snapshots of your data you should start with a big volume (i.e. 2x400 = 800gb) asuming that all the data in the LUN have changed and you need to keep the old image in one snapshot. Leave it running for some days/weeks and see what the actual stats are with df. Remember as snapshots grow older they grow larger too (more changes accumulated), so you might consider keeping snapshots for a small time (and then moving to backup for example). This needs a snapshot and backup policy to be defined.

2. If you cannot delete all the snapshots and start fresh, then you have no option but to enlarge your volume say to 750 or 800gb. Then leave the host running for some time and the same time recycle your snapshots depending on why they are used. If they are used for snapmirror/snapvault do some mirror updates to clearup the old snapshots and create newer (and smaller) ones. If they are used for backup reasons, create new ones and delete the older ones. New snapshots are always small in size. I guess your existing snapshots will be old by now and this explains their size. Build a snapshot policy with not too old snapshots and leave it running for some time to clear the old large snapshots. After you have come to a balance, you will see how much space snapshots actually occupy with df, and reduce the volume size to something normal, e.g. +30% above used space.

At this point you probably have old snapshots, you have brought the LUN online/offline several times, data copied in by the host several times and this makes your snapshots grow above normal. It is important to start fresh somehow and bring your volume to a balanced size.

Let us know how it went and what your concerns are. I am not sure what you mean with "not sure if I can delete the snapshots.". Why is this? Who creates the snapshots?

If space is a concern to you, you do need a snapshot policy, however simple or complex it may be. But first you have to get the system running.

TDUBB1234 · ‎2012-07-11

hello

today df -V -h shows

/vol/vol1/ 448GB 351GB 96GB 78% /vol/vol1

/vol/vol1/.snapshot 298GB 274GB 24GB 92% /vol/vol1/.snapshot

so the used went down from 384 to 351. Is this the actual lun or drive seen on the host system?

the snap looks like it went down too but I did not delete anything.

the snap I believe are from our commvault snap backups. but we have disabled those since.

Is it better to enable lun reservation?

thanks a lot

ivisinfo · ‎2012-07-11

since you have lun reservation disabled 351gb is about the actual data in the LUN, as seen from the host.

if you enable the lun reservation you will always see 400gb used in the volume, no matter if the LUN is full or empty from the host.

it is nice that the snapshots have decreased. This happenned because a newer snapshots was created and the older one deleted.

leave it running like that for some time and check the sizes. You still have the risk of snapshots getting too big, if for example if the host deleted all the 351gb and wrote fresh data in. The snapshots would then get all the old 351gb (to be able to restore to the previous state) and eventually your volume would get full. Unfortunately, you cannot avoid this risk. Enabling lun reservation will not help with such situations of snapshot size increase.

if you want to be ~100% sure that there will be no problems with full volume and the lun getting offline, you have to:

enable lun reservation
define a policy for automatic volume growth and/or automatic snapshot deletion for this volume

If snapshots are important, i.e. applications rely on them, and not just for backup reasons, automatic snapshot deletion is acceptable provided that you have other backups of your data.

Automatic volume growth is also acceptable, given that you have space in your aggregate.

Both methods are helpful, and can save you from vol offline situations,

Snapshots are a greate way to have instant online backups with small space requirements, and very fast restores, but their size is statistical, depending on the changes made from hosts. This is the caveat.

Thin provisioning (lun reservation setting) is also a great way to save space especially in complex environments, because you can sum up and save all the free data not used by hosts. But again the caveat is that this is also statistical.

In all cases, these are statistical data and you cannot be 100% sure, so you have to monitor the system, create auto growth policies, and remediate afterwards, checking what happenned with the snapshots, vol size etc.

Hope I have helped

aborzenkov · ‎2012-07-11

Enabling lun reservation will not help with such situations of snapshot size increase.

That's what Fractional Reserve is for ...

TDUBB1234 · ‎2012-07-12

ok thanks.

ok so I create 2 vols of 500g. also 2 luns

but on one lun, it only allows me a max of 498gb.

i tried

lun create -s 500g -t vmware /vol/vol2/vol2_qtr/lun2

lun create: max size: 498gb

but on my other vol/lun the lun is 500.1gb.