High value of file system overhead observed in the vSAN capacity breakdown with dedup enabled

Products

• VMware vSAN

Issue/Introduction

Symptoms:

• For ESXi hosts in a vSAN Cluster with de-duplication and compression enabled, the Used Capacity Breakdown (Monitor > vSAN > Capacity) for a vSAN cluster displays a large number of file system overhead (fsOverhead). This number does not reflect the actual capacity being used in physical disk for file system activities.
• This behaviour is observed in empty clusters or clusters with minimal data consumption. As cluster capacity utilization increases fsOverhead will normalize.

Environment

VMware vSAN 6.6.x
VMware vSAN 7.0.x
VMware vSAN 6.5.x
VMware vSAN 6.7.x

Cause

• On a newly created vSAN cluster with deduplication and compression enabled or on a cluster with low capacity utilization, File system Overhead (fsOverhead) shows up as a majority contribution in the Used capacity breakdown.
• This is because the fsOverhead is determined to be a logically fixed constant factor (around 1%) of the maximum cluster capacity which is allocated upfront.
• In non-dedup enabled environment, maximum cluster capacity is total physical disk capacity.
• In dedup enabled environment, due to the deduplication and compression introduced, we regard maximum cluster capacity to be 10 times of total physical disk capacity which resulting in File System Overhead to be 10% of total physical disk capacity.

Please note that in dedup enabled environment:

• fsOverhead of around 10% of physical disk capacity is an estimated size.
• It can be regarded as reserved size since in most cases, the fsOverhead size is not full of used data
• It is a space reservation before deduplication and compression, so the actual written size on a physical disk will be less than 1% of total physical disk capacity in most cases.
• This will dominate the usage of the cluster under such circumstances. When the disk groups start filling up the utilization graph will start to level out and reflect the percentages more accurately.

Resolution

This issue is resolved in vSAN 7.0 Update 1, available at VMware Downloads.