Files scale-out versus a second file server for SMB metadata pressure
A university department runs Nutanix Files on a six-node AHV cluster. The file server was deployed with three FSVMs and hosts two SMB shares: \files\dept (40 TB, 1,500 users, access-based enumeration enabled) and \files\home (20 TB, 1,500 home directories). A separate NFS export serves 20 Linux render nodes with scratch data. Since migrating from a legacy NAS, users report 8–15 second folder enumeration in deep project trees and occasional SMB disconnects during the 08:00 logon storm. Prism shows all three FSVMs at 85–95% CPU, about 3 Gbps per FSVM, and an antivirus scan that touches 1.2 million files nightly. The department wants to add a fourth FSVM immediately. Budget allows either one additional FSVM or a second file server with three FSVMs. Security requires ABE and on-access antivirus. The Linux team refuses to move render scratch data off the NFS export. What should you recommend?
1. Is adding a fourth FSVM to the existing file server the right first move? Justify your answer using Files scale-out behavior and the evidence in the scenario.
Read the worked answer
Not automatically. Nutanix Files scale-out adds an FSVM to increase aggregate CPU, memory, and network capacity, and shares are distributed across FSVMs. All three FSVMs at 85–95% CPU and roughly 3 Gbps each show a real aggregate constraint, so a fourth FSVM is defensible and fits the common four-FSVM design. However, it will not fix a single hot share if that share is pinned to one FSVM. The symptoms split by workload: the 08:00 disconnects track the home share, while 8–15 second enumeration tracks deep trees in dept. If dept is one share on one FSVM, the fourth FSVM may sit idle for that share. Before buying, check share-to-FSVM placement and split dept into team or project shares so the new FSVM can take work. The 1.2 million-file nightly antivirus scan is also a metadata multiplier; use vendor-recommended exclusions and scan windows, not blanket exclusions that violate security. Given the budget choice, the fourth FSVM is the lower-disruption step if share splitting is done; a second file server is better only if you need hard isolation between home and dept or expect to exceed four FSVMs.
2. How should you lay out SMB shares, the NFS export, and antivirus to reduce metadata pressure without weakening ABE or on-access AV?
Read the worked answer
Split the 40 TB dept share into several SMB shares by department or project, and publish them under one DFS namespace so users keep a stable path. That gives the file server more schedulable units across FSVMs and limits the blast radius of a hot folder. Keep home directories in their own share; do not mix home and project data. Put the NFS export on a separate share and, if possible, a separate FSVM so Linux scratch I/O does not compete with SMB metadata. Enable ABE only where folder visibility matters, such as dept, and measure the cost; do not assume ABE is free. For antivirus, keep on-access scanning but use the vendor's Nutanix Files exclusions and a write-first policy, then move full scans off-hours. If security will approve, exclude only reproducible scratch or temp paths, not user documents. Rebalance or remount shares after adding the FSVM so the new capacity is actually used.
3. What specific metrics and tests would prove the change worked?
Read the worked answer
Baseline and then compare p95 folder enumeration time for deep dept paths, SMB metadata operations per share, FSVM CPU per FSVM, network throughput per FSVM, antivirus scan duration and files scanned, and SMB disconnect events during the 08:00 logon window. Also record which FSVM hosts each share before and after. A successful change should show lower p95 enumeration, FSVM CPU below about 70% at peak, no disconnect spike, and a shorter AV scan that no longer overlaps logon. Run a controlled logon storm with a pilot group before declaring success.