Volume usable size and lun

[deygaurab]

Hi,

I have trying to understand the space usage a volume displays when a lun is created in it. For example,

volume size =625g (guarantee=none)

lun size=500g (space reservatio=disabled)

FR=20%

There is a snapshot(snapmirror) in te volume

The lun show -v command reports the lun consumtion as 363g

The df -g output of the volume reports 27gb usaed and 597gb free. whereas the host sees 90% utilised for the same lun mounted as a datastore? I am having a hard time understanding this equation. If the volume usage reported more than the what is reported in the host side than I would have understood that that there was sme changes in the data and space reclamation needed to be run. But I am not able to understand why would a volume report only 27g of usage and 597g of availble space.

Any suggestions would be greatly appreciated.

Cheers

Rahul

[aborzenkov]

please, show ouput of

lun show -v

df -h

df -rh

aggr show_space

[aborzenkov]

Interesting. Are you using deduplication on this volume?

[paulstringfellow]

I would suggest its because you have a thin provision LUN.

How much data is actually on the LUN as far as the OS is concerned?

[aborzenkov]

I always was under impression, that “Occupied size” is exactly the actual amount of data on LUN. I may be wrong; do you know what this field means?

[paulstringfellow]

I’d agree, that that is what you’d expect…however I think it means how much data has been written to the LUN…

I think the useful starting point would be to find out how much data the OS actually sees as been on the LUN and from there we can probably work out what’s happening…

It an odd world really because of the disconnect between what the OS thinks is on a disk and what is actually in the LUN…seen it this week..where LUNS are filled…however the OS says its only using 60% of the disk…but its caused by data been deleted…hence space reclamation…

Not sure the ontap commands are an exact science for stuff like this…be interested to see the actual disk usage shown by the OS and work from there…

[aborzenkov]

More likely it is due to “A-SIS = 97377440KB”, which is “Amount of disk space used by deduplication metadata in the aggregate”. I bet on active deduplication ☺ Rahul, could you additionally show output of “df -s” (I always forget this option, sorry).

[deygaurab]

Thanks Aborzenkov, below is the output of df -s

Filesystem                used      saved       %saved

/vol/volxxx/          29105600  351716240          82%

Paul,

From the host side, the used capacity is shown as

500G  440G   59G  92% /vmfs/volumes/NetApp-DP-T-120-xxx

If the volume usage showed more than what the host is reporting, than I would have understood that space reclaimer needs to be run as there might have been lot of data changes from the host side. Since the usage on the host side shows more than what the storage is reporting, I got confused.

Cheers,

Rahul

[aborzenkov · Accepted solution]

So you have here 360+G your LUN occupies. We found it ☺

[paulstringfellow]

Think the dedupe stat tells you everything there…getting 92% dedupe…hence the space saving…

Gotta love that NetApp technology!!!

[deygaurab]

Many Thanks Paul & Aborzenkov

This space saving is visible from the stotrage end. But the host sees it 88%. Yesterday it was seeing 90%. So I assume,
2% of usage reduced from the host side. What if the sysadmin asks for more space seeing  the datastore reaching 90% whereas
in reality, there is lot of space available on the storage.

[deygaurab]

Gentleman,

Any thoughts on my last query?

Many thanks for your help .

Cheers

Rahul

[columbus_admin]

Rahul,

      You will have to give them more space.  The host file system does not know that the back end storage is deduplicated.  As far as the host knows, it is using the full amount of space that it wrote to the disk. 

Basically the storage system is lying to the host, and the host has to report what it has been told.  The host will "run out of space" if what it believes the LUN utilized size to be is maxed out.  Generally you have to be willing to over commit when using deduplication.

- Scott

[deygaurab]

Hi Scotts,

Thanks a lot for clearnig my doubt.  If the host is not able to get the benefit of deduplication , how does it help? Even though I am saving space from the storage side, but in the hindsight I am providing more space from the storage. I guess, the trick here is the thin provisioning of the luns along with dedup. When the host reports full, the lun size is insreased. The space from the storage gets used when the actual usage happens. In a nutshell, the storage is completely lying to the host

Let me know if my thoughts are correct.

Cheers

Rahul

[deygaurab]

In short, deduplication benefits can be achieved in real time only when the lun space gurantee is disabled?

-Rahul

[columbus_admin]

This is where dedupe gets tricky...savings are always on the storage side.  And really, that is the only place it matters.  The host does not actually have that space, but it believes it does, and that is all that matters!  The host does get the dedupe benefit, just without knowing it is. 

If you were to do this without dedupe(and having the guarantee on), you would have to give the host the full 500g + expansion and that would be unusable space. 

With dedupe, you only give (500GB + expansion), but only use 27G+expansion, so there is still some benefit if you don't guarantee everything(some thin provisioning, some thick)

So to answer the question below maximum benefit is only achieve with dedupe and thin provision(no space guarantee on the LUN or VOL)

With dedupe and thin provisioning, you only give (27GB+(expansion - dedupe after the schedule runs)).  This means you re-allocate the same storage "bits" over and over again to the host!  The host doesn't care, because all of the data is still there, just taking up less space.

- Scott

[deygaurab]

Thanks Scott,

Do you have any whitepaper or KB fron NetApp which speaks about the host side relationship with the storage in case of dedup?

Cheers

Rahul

[columbus_admin]

Rahul,

     I don't have that great a link, but here is a quick "why is df different from what my host reports" - https://kb.netapp.com/support/index?page=content&id=2011260

"

This happens when A-SIS is used on a volume. A-SIS is a block level deduplication protocol and as such does not effect the files themselves. The df command on the filer reports block level space usage.

Client side space usage tends to be calculated based on the files size, not on block usage. With A-SIS running on the volume, the client will report usage based on total file size while the filer will report space usage based on block level usage."

- Scott

[deygaurab]

Thats a valueable piece of info Scott.

Does ASIS save space on fractional reserve too? Here in my exapmple, my volume had 20% of fractional reserve for a lun of 500g whose usage was 360g.  There was a snapmirror snapshot present in the volume, so I would assume 20% of 360g to be reserved for overwrites which comes out to 72g. Since my volume space usage is reporting as 27g used, I would assume the volume is not taking in to consideration the 20% fractional reserve when displays usage report.

Ideally my volume should have reported 72g+ dedup saved. Any thoughts on this Scott.

Many thanks for your response.

Cheers

Rahul

[deygaurab]

Folks/Scott,

Any advise on my above query?

Thanks in advance

Cheers

Rahul

[scottgelb]

df -r will show the reserve used... it isn't deduplicated...but the data that goes in the snapshot was de-duped prior to snapshot so you do get more savings in the snaps too...so likely can decrease that reserve if a lot of excess space.