If you've deployed a Nutanix Files server you may notice there is one set of numbers provided on the File Server dashboard to describe space usage. On the storage dashboard you may see noticeably different figures for space usage in the container, even though the Files server is the only thing residing in that container.
The first thing to understand about this is that both sets of figures are valid. They differ because they represent different perspectives on storage space usage. It helps to keep in mind that the Files deployment is a set of virtual machines.
The File Server VM (FSVM) cluster manages its own filesystem on top of the attached VGs, and the storage space details shown on the File Server dashboard are from that perspective. You might be thinking "well duh!" but this simple fact is essential to understanding the explanations that follow. We can set aside the fact that the FSVMs as a cluster use multiple volume groups made up of several vDisks. We can think of it as a single VM with a virtual disk, and the same storage accounting concepts would apply in either case.
Let's review the figures on the File Server dashboard. These figures are described in the Nutanix Files Guide. Space Used shows the total used space as seen from within the file server's filesystem. You might guess Space Used by Snapshots has something to do with the protection domain created for Files, but this is actually referring to snapshots created within the file server. See this section of the guide for more details. Total Available Space and Size also are in reference to the file server's file system. These numbers correlate to AOS storage container usage numbers in the same way Windows VM's NTFS filesystem usage correlates to the back-end storage usage. The VM cannot account for how data blocks are managed in AOS, it simply manages the filesystem it created, and that is the space usage perspective we see in the File Server dashboard in Prism.
So when we look on the Storage dashboard in Prism and review the container where the file server is stored, we shouldn’t expect a one to one match at all with the usage figures seen from inside the file server. The first reason is pending deletions. The file server can consider previously used space to be free and ready to use again as soon as a file deletion is done within the file server (after file server internal snapshots are expired), but before that space becomes free in the container we need the file server to send “TRIM” (a.k.a “UNMAP”) commands, then any snapshots at the container level would need to expire, and then clean-up of deleted blocks could happen in AOS. This is actually true for all VMs, but I wanted to point out here that this is equally true for the file server.
In addition to pending clean-up, we will see further space discrepancies. Compression, deduplication, and/or erasure coding would decrease space used at the container level, and those pending deletions, DR snapshots, and data redundancy (RF2 or RF3) will add to space usage at the container level. These discrepancies aren’t at all exclusive to Files servers, but it’s worth understanding.
I won’t go into all the detail of storage efficiency management here, if you’re looking for that you should check out the Data Efficiency tech note. I will mention here that clean-up is a lower priority operation and freeing up space tends to take longer on busy systems. Also, enabling compression is rarely a bad move. On Nutanix systems data compression can actually improve storage performance overall by allowing more data to be cached in memory for fastest-possible read response times.
If you’re looking to free up some space and you want to know how to clear some of those in-file-server snapshots, take a look at the article “Nutanix Files - Reclaim space by deleting Nutanix Files internal snapshots (SSR and CFT snapshots) from cli”.