Almost every unexplainable behavior about Storage Spaces revolves around the “Column” concept. When you do things from the UI instead of PowerShell, you don’t get to choose the most optimal column count. I can speculate that because you used 3 disk configuration initially, the column count of the vDisk ended up being as “3″. Now.. Since the disk needs to be parity protected, and is already FIXED to occupy all of the remaining disks, in order for it to get extended over to the 4th disk, it is probably failing to find a space to hold its parity.

Before continuing to read, do this:
- Launch PowerShell and run “get-virtualDisk | fl” review the column count.
- Use the Storage Spaces UI to get to the “Health” view of the virtual disk. When you expand the details of each disk, you’ll see that they will all be showing 0 free space.

Now.. on your 4th disk, you’ll have 100% free space, but there is no other disk to keep the parity on. For this reason extend action will fail.

You could try to first shrink the volume, make up some space; then extend over to the 4-disk set.

lastly, the column count. Every column has to be stored on a different disk. If your vDisk is formed using 3 columns, you’ll need free space across all 3 of them to do any kind of expansion.

Rough math on this works out like this:

4 disks:
1TB with 100GB free
1TB with 100GB free
2TB with 60GB free
3TB with 2TB free

what can you create?
3-column parity: ~200GB (it will need to form 100+100+100GB 3-column footprint for it. 1/3rd will be parity, you’ll get 200GB usable, roughly. If you noticed, I picked 100 because that’s the largest common free space across any 3 of the 4 disk set)
4-column parity: (it will need to form 60+60+60+60 and give you 3×60=180GB free as 1/4th will go to parity, roughly. Again, 60GB is the largest common free space across all 4 of the 4 disk set)

Does this help?

(Happy to stand corrected on my math of concepts here; although I blogged about Spaces, what I included as sample here is not authoritative info from Windows engineering team — I learnt concepts through experimentation and might have errors in them. Absolutely feel free to poke holes and correct my response.)

I created 5 iSCSI Targets (LUNS) on my iSCSI Storage with same capacity (for example 100 GB each), and connect all LUNS to my WinSrv2k12. They are listed as “Primordial” in “Server Manager\File and Storage Services\Volumes\Storage Pools”. I created a new Storage Pool named StPool1, including three of available five disks. Now I created a Virtual disk, with provisioning type=FIXED (instead thin), with maximum capacity, and layout=parity (it doesn’t not matter which parity type I choose). Then I created a volume, formatted and till now all is OK.

Now I trying to add another physical disk (one of other two, not used till now) to my StPool1, no problem. But… When I try to extend the virtual disk, all time the process finished with error “The physical resources of this disk have been exhausted”. As I saw, it doesn’t matter of parity type, and how many physical disks I add later to the pool. If provisioning type of my Virtual disk is “Fixed”, this error occurs.

Can you explain me why this happens?

Also FWIW, Settings/About/More: shows HW revision as 1.0.0.0. What does yours show?

so perhaps taking with you a magnifying glass could help? Let me know if any of you know of a hw difference.