topic How is this lun thin provisioned? in ONTAP Discussions

How is this lun thin provisioned?

jwwags922 — Thu, 05 Jun 2025 06:55:01 GMT

New Netapp Admin here. I found the following volume in my environment:

VFiler1*> vol size ESX_Test_Vol9
vol size: Flexible volume 'ESX_Test_Vol9' has size 500g.

It has the following LUN:

VFiler1*> lun show /vol/ESX_Test_Vol9/esx.lun
/vol/ESX_Test_Vol9/esx.lun 650.1g (698030161920) (r/w, online, mapped)

So, it's a 650GB Lun in a 500GB volume.

Lun space reservation is enabled.

VFiler1*> lun set reservation /vol/ESX_Test_Vol9/esx.lun
Space Reservation for LUN /vol/ESX_Test_Vol9/esx.lun (inode 102): enabled

Space guarantee is set to 'Volume' and not 'none' as seen below. I thought I had my head wrapped around this. Apparently I don't. Any help is MUCH appreciated. How can the Lun be larger then the volume. Is there an aggregate setting I don't know about?

VFiler1*> vol status -v ESX_Test_Vol9
         Volume State           Status            Options
ESX_Test_Vol9 online          raid_dp, flex     nosnap=off, nosnapdir=off,
                                sis               minra=off, no_atime_update=off,
                                                  nvfail=off,
                                                  ignore_inconsistent=off,
                                                  snapmirrored=off,
                                                  create_ucode=on,
                                                  convert_ucode=off,
                                                  maxdirsize=167690,
                                                  schedsnapname=ordinal,
                                                  fs_size_fixed=off,
                                                  compression=off,
                                                  guarantee=volume, svo_enable=off,
                                                  svo_checksum=off,
                                                  svo_allow_rman=off,
                                                  svo_reject_errors=off,
                                                  no_i2p=off, fractional_reserve=0,
                                                  extent=off,
                                                  try_first=volume_grow,
                                                  read_realloc=off,
                                                  snapshot_clone_dependency=off
                Containing aggregate: 'aggr0_sata'

Plex /aggr0_sata/plex0: online, normal, active
RAID group /aggr0_sata/plex0/rg0: normal

        Snapshot autodelete settings for ESX_Test_Vol9:
                                        state=on
                                        commitment=disrupt
                                        trigger=volume
                                        target_free_space=15%
                                        delete_order=oldest_first
                                        defer_delete=user_created
                                        prefix=(not specified)
                                        destroy_list=none
        Volume autosize settings:
                                        state=on
                                        maximum-size=1021732452 KB
                                        increment-size=20 GB

Re: How is this lun thin provisioned?

aborzenkov — Thu, 12 May 2011 05:20:37 GMT

Is deduplication active for this volume?

Re: How is this lun thin provisioned?

chriskranz — Thu, 12 May 2011 07:16:50 GMT

I think this is probably a "quirk" of the NetApp system.

All volumes and LUNs are always "technically" thin provisioned. The only real difference is whether a flag is set to make the data as not available. As you are using aggregates and FlexVols, all the data can be allocated on any area of disk (one of the many benefits of WAFL, Aggregates and FlexVols). This means that any volume or LUN you create, whether created thin provisioned or not is never assigned a specific portion of disk, but simply the "free space" within the aggregate or FlexVol is reduced.

You can get into situations where you over-allocate volumes without really meaning to. This may cause you a problem down the line if you try to write 650GB of data, but then so would a thin provisioned LUN. I would guess that if you tried to create this using normal procedures you'd be disallowed, but by changing a LUN/FlexVol from thick to thin and back again, you'd be able to achieve what you are finding. I haven't got my sim running at the moment so can't test it for you I'm afraid.

In this situation I might recommend shrinking the LUN or growing the FlexVol to fix this as you probably don't want to be in this situation.

Out of interest, what does the output from "df -h", "df -r" and "df -s" look like?

Re: How is this lun thin provisioned?

jwwags922 — Thu, 12 May 2011 13:02:22 GMT

First of all, thank you for your response.

The volume is Deduplicated, with a 60% space savings being reported df -s

df -h demonstrates the volume size is 500GB.

VFiler1*> df -h /vol/ESX_Test_Vol9
Filesystem               total       used      avail capacity Mounted on
/vol/ESX_Test_Vol9/      500GB      263GB      236GB      53% /vol/ESX_Test_Vol9/
/vol/ESX_Test_Vol9/.snapshot        0MB     6822MB        0MB     ---% /vol/ESX

I found a thread describing a way to do this using Netapp System Manager. basically, you get the lun setup the way you want, and then shrink the volume. As long as there as free space within due to lack of data or dedupe, you are ok. I assume the volume size command would shrink the volume even if it had a lun "bigger" then the volume?

I was hoping I could change the question a little bit. More into, How do I find more of these? It seems like right now, I'd have to grab a list of volumes, pull a list of all luns on those volumes. get the sizes of each and compare. I was more hoping for a simple flag!

Jason

Re: How is this lun thin provisioned?

aborzenkov — Thu, 12 May 2011 14:17:37 GMT

Yes, it is possible to shrink volume below logical LUN size. At the time of executing “vol size” NetApp counts physical space consumption, not logical. So if your LUN is 60% deduplicated, it actually consumes only 260G on file system which is shown in “df –h” output.

If you think about it a bit, this is pretty much logical. After all, the whole point of deduplication is to be able to store more data than physically fits on storage. It does not matter whether this is single file or multiple files – the point is, sum of logical sizes exceeds physical volume space.

I do not think there is single command to do what you want. As mentioned, you also can have many files, each one being relatively small but in total exceeding volume size. It should be relatively easy to script though.

May be if you explain why you need to compare LUN size with volume size someone could suggest alternative way to do it.

Re: How is this lun thin provisioned?

jwwags922 — Thu, 12 May 2011 14:53:40 GMT

I think I'm good. Thanks for talking this through.