2012 R2 SS, Parity Mode + SSD config build log

[cesmith9999]

your end goal is to have a 10+2 configuration. that is where your column count requirement comes from.

 

[ninja6o4]

ah ok, I gotcha. so there really isn't any easy way to expand the storage pool and vdisk at a later date. Guess it's time to keep an eye out for some hard drive sales..!

 

[cesmith9999]

You are correct.

Expanding the storage pool is easy, you just add disks

to change the column count on the vdisks, you need to use Thin provisioned vdisks

add the # of disks you want to add to the storage pool
you create a new thin vdisk with the new column count
you slowly migrate your data to the new vdisk
migrate 1 tb to new vdisk
defrag /k on old vdisk
rinse and repeat

Like I said. if Microsoft had a mechanism to change a vdisk column configuration. It would solve this issue. I am hoping that it will be in the next version.

Chris

 

[ninja6o4]

Ah you're right. With thin vdisks, there would be nothing stopping me from adding as little as 1 additional drive to the pool and create a 13 column+dual parity vdisk, so long as I am willing to migrate data from vdisk1 to vdisk2.

Obviously I wouldn't do just 1.. but just to illustrate. Thanks a bunch for your input on this!

 

[ninja6o4]

Just to update.. I have completed migration to the temporary vdisk and am now in process of the migrating over to the new one. It will be quite slow as I had to fill the temp vdisk completely, leaving very little room for the final vdisk to expand itself. I am starting in 100GB/defrag increments until I can get enough breathing room to hit 1TB per transfer, lol!

For posterity, this was the command I issued. The goal is a 12 column, 12 HDD, dual parity vdisk, using 3 SSDs assigned as Journal drives. No storage tier (not available in Parity mode.)

New-VirtualDisk -StoragePoolFriendlyName MetroPlex -FriendlyName DualParity -ResiliencySettingName Parity -ProvisioningType Thin -PhysicalDiskRedundancy 2 -WriteCacheSize 100GB -Size 27TB -NumberOfColumns 12

Interesting note: WriteCacheSize has a hard limit of 100GB, even though my SSDs are 256GB in size. Didn't see that documented anywhere in my googling, so I'm just putting that out there.

 

[cesmith9999]

Congrats,

Nice to know that this is working.

Also nice to know that the WBC has a limit.

you might want to create a separate 6 column vdisk to migrate some data from your first vdisk. this will free up more space from the first vdisk to migrate data to the 12 disk vdisk faster.

 

[ninja6o4]

Hmm.. I've been moving data off but defrag is unable to recover the space. I've tried both defrag and Optimize-Volume. This is the result:

Slab Consolidation:
VERBOSE: Space efficiency = 97%
VERBOSE: Potential purgable slabs = 67
VERBOSE: Slabs pinned unmovable = 67
VERBOSE: Successfully purged slabs = 0
VERBOSE: Recovered space = 0 bytes

I have over 600GB free in the temp vdisk, yet the disks report they are still completely full (0 bytes free.) It seems to be unable to purge the empty slabs. I'm scratching my head over this.. If I find the solution I'll report back.

 

[cesmith9999]

run defrag /x (file consolidation) as well as defrag /k

defrag /k (slab consolidation) is not 100% effective.

this is also why I was recommending a temp 6 column migration vdisk. to free up more space from the 1st vdisk.

Chris

 

[ninja6o4]

run defrag /x (file consolidation) as well as defrag /k

defrag /k (slab consolidation) is not 100% effective.

this is also why I was recommending a temp 6 column migration vdisk. to free up more space from the 1st vdisk.

Chris

Yup I've been running them with the /k and /x switches, and the equivalent for Optimize-Volume to no effect.

I just set up a temp migration disk again, and going to test that it actually will shrink when I need it to.. lol I'll update shortly

edit: OK I think I figured out the problem. I initially set up a temp migration disk, formatted as ReFS, and it absolutely would not give up the slabs after I copied 20GB over and deleted it.
I wiped it out again and made a new one as NTFS, did it again with 100GB of data and now it is relinquishing the slabs like it should be.

After moving a few items off, and taking advantage of the larger 2x 6TB drives I ended up buying, I made the temp migration disk an 8 column parity vdisk. This should leave me 5TB of overall space leftover, which should be plenty after I begin the final migration/shrink temp disk process

 

[ninja6o4]

Very interesting development.. Overall progress has been slow (10-30MB/sec, not unexpected), but around half way I was checking some of the disks and their usage. Since I posted on Friday I was moving data from my first vdisk to second vdisk. Checking it now, the first vdisk that I was originally unable to shrink with defrag or Optimize-Volume was reducing its allocation on the physical disks automatically (?!)

It was just under halfway at this point, so I stopped the file move operation, and created my final destination vdisk, a 12 column, 12 disk, thin provisioned, dual parity vdisk, with 3 SSDs for Journaling (Write Cache):

New-VirtualDisk -StoragePoolFriendlyName MetroPlex -FriendlyName DualParity -ResiliencySettingName Parity -ProvisioningType Thin -WriteCacheSize 100GB -Size 27.3TB -NumberOfColumns 12 -PhysicalDiskRedundancy 2

So now, I have my first temp vdisk sitting with 9TB of data, and my second vdisk sitting with 8TB of data. I will finish moving the data off the first vdisk and kill it off before emptying the second vdisk.

Performance is really suffering now - with dual parity, and reading/writing to the same disks, I expect this final stage to take close to a week. I just hope it's worth it!