I have a volume that is 7T in size. It has 40% snapshot reserve, so we are left with 4.2T usable. My GUI shows that the available space is 820G, however when i run an inventory via both linux and windows, i only see 2.1T used. So 7 * .6 - 2.1 - .8 = 1.3T. I should have an extra 1.3T that is just missing. I can't seem to find it.
Remember that while snapshot reserve marks some space available for snapshot use only, if snapshots need more, they will take more up to the available size of the volume.
Without more detail about your snapshots, it's hard to say if that is going on, but given you have a 40% reserve (reflecting a large changed data rate or long retention or both) I'd hazard a guess that your snapshots are actually using more than the 40% you reserved for them.
There isn't any option to limit how much space a snapshot is allowed to consume, or said more formally, how much change is allowed to the volume after a snapshot is taken.
Another possibility to consider is the number of files being used and if they are small files. Remember that the basic unit of allocation on a NetApp volume is a single block, or 4K. Thus every file takes at least one block, or 4K. If you had a 10000 files that averaged around 2K in size, your OS could show space "used" of around 50% of actual physical space used. Depends on how you measure the space - by user bytes consumed or physical blocks consumed.
The snapshot reserve -as far as i'm aware, never hits that max number. When watching it throughout the day it grows to about 700GB, but never hits anywhere near the 2.8G that it is allocated.
When a linux admin does a du on /vol/ddsweb, it returns 2.1T - the same i get when i select all subfolders (and files on the root) of the share/export. So for some reason, the NetApp is telling the system that it is using 3.8G, but when an inventory of the files are done - it is only showing 2.1T used.
interesting bobhouseofcards, i didn't know about that. This share has 590k files - which if all of them are a small amount would make up 2.3T...but i don't really know the composition of the files within, so there could be some very very large files but most of them are tiny --- not sure...is there any way that i can confirm this without looking at each file independently?
The block size factor is a common thing to not be aware of. In typical user file systems these days we are schooled to allocation units of 512 bytes, so the "wasted" space factor is generally minimal until you get to beyond millions of files.
As you indicate, with your 590K files, your minimum starting space used is 2.3TB. With that many files, it wouldn't take much to get to 3.8TB. NetApp stores every thing as files using an "inode" model much where file meta data and if small enough the actual file data are stored together in the first block. So even at 4K, a file takes a minimum of 2 storage blocks. If roughly half of your files are at least 4K, you are already using at least 3.3TB. It doesn't take much more to get to your 3.8TB.
"Lots" of small files is one place where most any eneterprise storage system has to make compromises. They could use a 512 byte block size, but that also increases file system overhead maintenance by more than 8x. At scale that becomes hugely important. 4K native block size is a good compromise between overhead space and performance, but there are edge cases that expose the block size as a liability. Lots of small files is one of them.
Depending on your environment, there is a way to address this particular case. If you know you will have lots of small files, it would be more efficient from a space point of view to provide a LUN from the NetApp to a Linux server. That server could create a filesystem on the LUN that uses a smaller block size internally, like allocation units of 512 bytes. Then the server can share it via NFS. Of course, there are tradeoffs. The Linux server is a single point of failure. Because the Linux server's read/write size would typically not align with the NetApp block size, NetApp performance would decrease. You need NetApp iSCSI/FC protocol licensing and the appropriate connections. And there is overhead through the Linux server as well. The whole configuration is more complex, but this configuration maximizes space usage, if that is the over-riding concern in a situation.
Well sure, I wasn't thinking that I would be able to get the exact number of "wasted" space based on the block size. But our calculations are off from each other by a multiple of 1024, so I guess what I'm trying to figure out is - are my 590,000 files using 2.25GB or 2.25TB based on block size alone.