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)
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.
Solved! See The Solution
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…
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).
Thanks Aborzenkov, below is the output of df -s
Filesystem used saved %saved
/vol/volxxx/ 29105600 351716240 82%
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.
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.
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.
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.
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.
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."
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.
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.