Storage Spaces Volume Reports full with 4TB free

Question

Hello Geniuses,

I have a Dell PowerEdge R640 with 7 1.6TB NVMe disks connected to an HBA (Non-RAID) running Windows Server 2019 Standard evaluation for a proof of concept deployment.

I've created a single "Capacity" Storage Pool with all 7 disks, this gives me 10.2TB of capacity in the pool.

In that pool, I've created a single thin provisioned parity virtual disk with a capacity of 8.00TB which is dedicated to Hyper-V storage. I formatted this disk using ReFS.

I deployed a single Hyper-V VM with success, that VM is up and running perfectly. I created a second VM which deployed properly and then shut itself off. After much digging I found that Hyper-V was complaining about disk space on the drive. Checking the disk, it showed about 3.5TB in use out of the 8TB. I powered down the VM, and started copying VHD files until the server started complaining about being out of space. This was again right around 3.5TB. Giving it one more shot I deleted all of the files I'd copied onto the server and began fresh with all new VMs. I created the two VMs and then started copying additional files onto the volume until I receive an out of space warning at 3.5TB.

I've checked this with the VMs running and powered off, and without VMs deployed on the server at all. All scenarios seem to end with insufficient disk space.

Nothing interesting turned up in the event logs, and I've been Internet searching trying to find some reference as to why an 8TB drive is throwing disk full errors at 3.5TB to no avail.

Answer 1

Hi OverwhelmedITGuy,

The understanding of "thinly provisioned storage" is that when you initially create a thinly provisioned virtual hard disk (VHD), it takes up less than 1 GB of space, regardless of the total capacity of the underlying VHD or VHDX file. The VHD does not consume any additional physical storage until data is added to the virtual hard disk. However, after other operations, the physical storage space will be consumed. Although a thinly provisioned VHD file declares physical storage space as needed, it does not free up storage that is no longer needed. For example, if a user temporarily copies 100 GB of data to a thinly provisioned VHD, the physical footprint of the VHD will increase by 100 GB. However, when a user deletes 100 GB of data, the VHD does not shrink back to its original size.
Based on your description, my advice is as follows:
Although the space of the virtual disk you configured is 8TB, but the space in it may not have 8TB of space, we right-click on the virtual disk to see the actual space it has, it may not reach 8TB of space. I experimented with the "Capacity" above and found that I could set it to 100TB or even 1000TB, and I actually didn't have that much space.
In addition, we can see that the Free Space in the storage pool has only 418GB left, and if this space is smaller than the size of the file you are copying, there will be an out-of-space error, just like on your screenshot.
Hope my answer helps you!

Best Regards,
Xu Gu

Answer 2

Hello Xu Gu,

I'm confused. When writing to volume H which is created under the storage spaces storage pool is when I receive the error that disk is full. If I move a folder of files onto volume H I receive disk is full message.

When I look at the properties for volume H I see plenty of space as below:

Are you saying that thin provisioned VHD files consume the full space provisioned to the disk so that I have no space available even though there's space available in disk properties?

To review. I have 1 storage pool created. In that pool are 7 NVMe disks of 1.46TB.
From that pool I created one virtual disk which consumes the majority of the space in the pool except 383GB.
The virtual disk shows capacity of 8TB

Drive H currently occupies 3.27TB of the 8TB leaving 4.73TB available in the thin provisioned volume.

Here is view of the volume H on the Hyper-V host from computer management:

The system acts as if the volume actually reaches capacity at 4TB instead of 8TB. I could not find any references to ReFS having such a limitation. If the partition was not GPT, or a format incompatible with volume of greater than 4TB I would understand this.