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.
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).
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.
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
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.