Storage Spaces: Understanding Storage Pool Expansion

BrandonWilson · ‎Sep 19 2018

First published on TechNet on Sep 24, 2013

If you’ve read my prior post about Storage Spaces , or about how to import a storage pool , then the discussion here will be a good addition. One of the clear advantages of using a storage pool is the ability to expand the pool by adding additional storage. That is great if you’re doing any thin provisioning and reach a point that you need more space. Perhaps you’ve simply acquired some additional drives. Adding them to the pool is fairly easy: right-click on the storage pool and choose Add Physical Disk…

Some of you have tried this and found it easy. Once you’ve expanded an existing pool, you can add other virtual disks or even extend those you have. However, there are occasions where attempting to extend a virtual disk can be problematic…and for good reason. However, the reason may not seem readily apparent. This difficulty can be further confusing if some virtual disks extend, but others indicate they are using the maximum available space while the pool continues to have unused space available.

How virtual disks stored on the pool?

The answer to that question depends on what options were chosen when the virtual disk was created. For instance, you may have selected mirroring or other options. To make this simple, let’s assume you had 5 disks in the pool at the time you created a virtual disk. Let’s also assume that due to whatever options were chosen for redundancy, the virtual disk (vdisk1) occupies space on disk similar to the following:

Figure 1: Virtual Disk Layout Example

In this example, the blocks for the virtual disk vdisk1 are distributed across 5 devices. Remember, also that Storage Spaces does not require that all devices be the same size to be part of a pool. Let’s also entertain the possibility of a second virtual disk (vdisk2) that is only spread across 3 disks. If you add a disk to the pool, it might look like the following:

Figure 2: Expanded Storage Pool

If you attempt to extend vdisk1, the maximum available space for that disk has already been realized even though additional space exists within the pool. This is because the layout required by the vdisk1 due to the options chosen at creation (mirroring, parity, etc.) are requiring 5 disks. Therefore, to expand vdisk1, you would need to add 4 more disks.

If you attempt to extend vdisk2, you would have the option to do so because that disk is currently spread across 3 devices and there exists available space across three devices to extend it. Storage Spaces refers to the arrangement of blocked storage as columns. So, in a pre-expanded state, vdisk1 uses 5 columns and vdisk2 uses 3 columns.

Vdisk2 might just be a virtual disk that used 3-way mirroring. Meaning that data on disk 1 is duplicated on disks 2 and 3. If you want to expand a virtual disk like that, it has to have the appropriate number of columns available to accommodate the needs of the virtual disk.

How can I tell how many columns a virtual disk uses?

Now that I’ve hopefully shed some light upon why extending a virtual disk within a storage pool can be problematic and why, I know someone out there is asking: “How do I tell how many columns a particular virtual disk uses?” The Get-VirtualDisk cmdlet in PowerShell is a great place to start.

Figure 3: Get-VirtualDisk

Get-VirtualDisk can tell you many things about a virtual disk you’ve created within a storage pool. Given no parameters it will display the virtual disks it finds with some basic status information. However, you don’t get the full picture. If you pipe the returned objects to Format-List, you’ll get much more detail…perhaps more than you want.

Figure 4: Get-VirtualDisk | Format-List

Notice that the number of columns appears in the listing as well as the parity layout. This particular virtual disk is different than the prior examples and uses 7 columns. Therefore, to extend it, the pool would need the appropriate number of columns available to accommodate the layout of the disk.