This thread has turned into a personal migration log for me, so I'll update the first post here. Hopefully it will help someone in the future that is planning a similar migration.
This is a great thread to follow if you are:
a) wanting to give 2012 R2 Storage Spaces a try and
b) have disks with data on them already
So I currently have a 2008 R2 server running Flexraid's tRAID storage pooling solution. In a word, it's.. troublesome.
Currently set up with 10x 3TB Red drives - 8x data, 2x parity. Using a single SSD "landing disk" as a cache for writes to the pool. It is strictly a media server for only 2-3 devices max - music, TV shows, movies. While I don't need high IOPS (just good write performance when ripping new content), I used to run a hardware based RAID6 and the disk write performance was excellent. On tRAID it is pitiful: 17-20MB/sec without SSD cache, or 40-42MB/sec with SSD. Combine that with general instability and questionable parity reliability and I've had it.
Anyway, I'm reading up on PigLover's research on SS and dual parity and it sounds promising. The questions I had earlier have now been answered, so I've revised it more into a FAQ style format.
Can I set up Storage Tiering and set up an SSD Tier to make things super fast?
I didn't try this, because you cannot use Tiering on a Thin Provisioned vdisk. The best option for Parity vdisks is Journaling and WriteBackCache.
So will this migration take a long time without Tiering?
Yes. Once your WriteBackCache fills up (quickly), expect write speeds of less than 40MB/sec.
Does the number of columns affects how many disks I would need in order to expand the pool, so if I do 8 columns, I need 8 disks; for 4 columns, I need 4 disks?
Yes
Would the number of columns have any affect on the overall performance considering my relatively low demand usage?
Yes, very much so. Read more here: Why Column Size does matter with Storage Spaces ← MIRU.CH
Third, is there any benefit for me to create smaller volumes to separate the various media catalogs vs. one large pool with subfolders for each?
None that I have found.
Should I use ReFS instead of NTFS?
No. Stick to NTFS. ReFS is not ready for prime time. It lacks many enterprise features you can read elsewhere. But it also does not currently support metadata tags (for music). I originally believed it was unable to shrink its volume usage, but it seems that my thin provisioned temp ReFS disk is, in fact, shrinking itself as I move data off of it.
Finally, 6 of the 10 disks overall have data on it already. What would be the best way to migrate this data? Here is the process I would do:
This is a great thread to follow if you are:
a) wanting to give 2012 R2 Storage Spaces a try and
b) have disks with data on them already
So I currently have a 2008 R2 server running Flexraid's tRAID storage pooling solution. In a word, it's.. troublesome.
Currently set up with 10x 3TB Red drives - 8x data, 2x parity. Using a single SSD "landing disk" as a cache for writes to the pool. It is strictly a media server for only 2-3 devices max - music, TV shows, movies. While I don't need high IOPS (just good write performance when ripping new content), I used to run a hardware based RAID6 and the disk write performance was excellent. On tRAID it is pitiful: 17-20MB/sec without SSD cache, or 40-42MB/sec with SSD. Combine that with general instability and questionable parity reliability and I've had it.
Anyway, I'm reading up on PigLover's research on SS and dual parity and it sounds promising. The questions I had earlier have now been answered, so I've revised it more into a FAQ style format.
Can I set up Storage Tiering and set up an SSD Tier to make things super fast?
I didn't try this, because you cannot use Tiering on a Thin Provisioned vdisk. The best option for Parity vdisks is Journaling and WriteBackCache.
So will this migration take a long time without Tiering?
Yes. Once your WriteBackCache fills up (quickly), expect write speeds of less than 40MB/sec.
Does the number of columns affects how many disks I would need in order to expand the pool, so if I do 8 columns, I need 8 disks; for 4 columns, I need 4 disks?
Yes
Would the number of columns have any affect on the overall performance considering my relatively low demand usage?
Yes, very much so. Read more here: Why Column Size does matter with Storage Spaces ← MIRU.CH
Third, is there any benefit for me to create smaller volumes to separate the various media catalogs vs. one large pool with subfolders for each?
None that I have found.
Should I use ReFS instead of NTFS?
No. Stick to NTFS. ReFS is not ready for prime time. It lacks many enterprise features you can read elsewhere. But it also does not currently support metadata tags (for music). I originally believed it was unable to shrink its volume usage, but it seems that my thin provisioned temp ReFS disk is, in fact, shrinking itself as I move data off of it.
Finally, 6 of the 10 disks overall have data on it already. What would be the best way to migrate this data? Here is the process I would do:
- Create temporary SS Simple thin vdisk in 6 columns:6 disks configuration (Be aware of the risks when using a simple vdisk - NO REDUNDANCY)
- Fill this pool with the data from the full drives
- Delete the old volumes from the now empty drives
- Create a second final SS Dual Parity thin vdisk, 12 column:12 disk configuration
- Move small portions of the data from temp vdisk to final vdisk - the final vdisk will run out of space as it is sharing physical space with the temp vdisk
- Use defrag /k and defrag /x to shrink the temp vdisk, giving the final fdisk room to continue growing.
- Repeat 5-6 until temp vdisk is empty.
- Remove temp vdisk, and we're done!
Last edited: