@SomeJoe777
Doh! You're right! I mixed the 2 together into a complete mess! Thanks for catching that one. I do know the difference, and I feel nooby for making that mistake. I was more tired than I thought.
Stripe size is a 'lower' level of cluster size. Stripe sizes again won't matter much for you. The reason that the stripe size won't matter is the same as cluster size, except that in VERY large stripe sizes(4MB+) you might see performance start to drop as your stripe sizes are so big you are practically reading from 2 drives at different times and starting to negate the performance enhancing design of RAID0.
There are advantages to keeping stripe size a multiple of NTFS cluster size, but usually that happens because you'd have to choose very wacky settings to not meet this thumbrule.
I will confirm that I did change the cluster size and not the stripe size as I wasn't using a RAID0. I wouldn't expect your setup to be any different even though you are using RAID0.
If you run benchmarks on various cluster sizes, the results may not give real world performance numbers. There's many factors that come into play with benchmark performance numbers making benchmarks almost unreliable for comparison just by changing the cluster size.
If you want to understand how cluster size works, read below:
Let's pretend you have a hard drive formatted NTFS with 2 files. 1 file is 1024k and 1 file is 1048576k(1MB and 100MB respectively). Cluster size is 4k for this scenario.
File number 1 uses 256 clusters(1024k/4k). File number 2 uses 262,144 clusters(1024k/4k). When you need to read file number 1 in it's entirety your OS will read the MFT(Master File Table) for the clusters the file occupies. It will then begin collecting up all of the clusters. File #1 has to read only 256 clusters(256 clusters will be listed in your MFT). File #2 however has 262,144 clusters listed in the MFT. What happens if we change the cluster size to 8k? Now file number 1 uses 128 clusters, and file number 2 uses 131,072 custers. This means that your files are using 1/2 the number of cluster entries in your MFT. This means less overhead for the OS as it has less clusters in the list to read, process, and request. For file #2 you saved 131,072 entries by going from 4k to 8k for a cluster size, but saved a mere 128 entries in your MFT for file #1. This is also good for fragmentation because the likelihood of 131,072 clusters being contiguous is more likely than 262,144. So now you might be thinking "Well, why not just go as big as possible? Seems like nothing is better than the smallest number of cluster entries as possible." Well, the downside to that is the cluster size is your smallest possible size to allocate. If you have a 1 byte file it will consume 1 cluster. If 1 cluster is 4k, that's 4k. If it's 128k, you'll lose 128k. This is known as slack space. The other drawback is OS tasks involving writing data write data in clusters. If you change 1 byte in a file the OS can't just change that 1 byte. It will instead write over that cluster again rewriting the whole cluster with the new information. That means possibly reading all of the data on that cluster, then writing all of that data again with the 1 byte difference. A 4k cluster size is clearly a better option if you have to write 1 byte difference. Using large cluster sizes for your page file is VERY bad for this reason. There's also some optimizations when your page file is stored on a partition with a 4k cluster size because the paged memory happens to also be in 4k blocks(if I remember correctly).
This space is being lost for every file on your system that isn't consuming a full cluster. This is why FAT32 aged so fast. Hard drive size grew rapidly(exceeding Moore's Law in a hard drive sense) and FAT32 had a finite number of clusters it could assign, so bigger hard drives meant larger cluster sizes. With larger cluster sizes meant more 'slack space' lost. NTFS has limitations also, but the limits don't start to become worrisome until you hit 16 exabytes(1 exabyte is 1 billion GB). Remember that NTFS was designed for business use, so NTFS was planned for the significant future. When NTFS was first designed in the 90s this limit was set. They definitely planned ahead because they designed this in the 90s and we still can't fathom even 1% of that.
Now, NTFS does have the ability to store files inside the MFT itself. In my case a 1 byte file would be stored in the MFT itself instead of allocating a cluster for it. Files that are so small that the allocation information would exceed the size of the file are stored inside the MFT. I don't know exactly what that limit is, but it seems to be somewhere betwee 3-5k from my experience.
--------------------------------------------
RAID Stripe Size:
RAID stripe size determines how large a 'unit' of data is on a drive. A stripe size of 512k means that every 512k is stored on the next drive.
In a 3 drive RAID0 setup:
0kb - 512kb - Drive 0
512kb - 1024kb - Drive 1
1024kb - 1536kb - Drive 2
1536kb - 2048kb - Drive 0
Remember this is below the OS and partition. This is what the RAID controller does. Bigger stripes mean less stripes, but also makes it more likely that small files will be on only 1 drive. There's ALOT that goes into stripe size performance and I don't think i should go into that tonight as that wasn't your question. I left this at default on my RAID setup as I don't want to use a 'nonstandard' number and if I need to use recovery tools it won't work with my 'nonstandard' settings.
-------------------------------------------
Now, you said you use a software RAID on your machine. I hate to disappoint, but software RAID can't be bootable 🙁. The reason is you have to load a significant portion of the OS before the software RAID drivers load, and in a RAID 0 the computer will start booting from the first hard drive. Unfortunately your OS is scattered on 3 different hard drives, and it has no way to realize this. It has no idea what 'striping' is. If you have a RAID controller the controller knows what striping is, because it's actually the one doing all of that work. Your computer will see 1 giant hard drive for the RAID0. It won't see multiple separate drives. Some diagnostic utilities will be able to recognize that multiple drives exist, but the OS will only see 1 giant "C" drive. There is a way you can do RAID1 software and it be bootable, but I have not done this and you have to do some basic windows registry editing and other tricks to get it to work AFAIK.
If you have booted from the RAID before, then you definitely aren't using a software RAID. If you set up the raid in a BIOS type environment it's hardware, otherwise it's software. I can't seem to get nvidia.com to come up where I am at right now, so I can't check out your motherboard info.
As for cluster size, you can use a program like Partition Magic and change your cluster size without losing data. I haven't tried to change the cluster size of my boot partition before via this route, but I would assume you can do it. It would just do a reboot and then change it. Do back up your data before performing this operation though.
I'm not too concerned about losing data - I have backups. Basically, I wanted to know what to expect when (if) I start making changes. 
Facebook
Twitter
Instagram