On 8/16/2012 2:08 AM, vincent Ferrer wrote: >> No it is not normal practice. I 'preach' against it regularly when I >> see OPs doing it. It's quite insane. The glaring maintenance problem >> is that when one SSD fails, and at least one will, you'll have 8 arrays >> to rebuild vs one. This may be acceptable to you, but not to the >> general population. With rust drives, and real workloads, it tends to >> hammer the drive heads prodigiously, increasing latency and killing >> performance, and decreasing drive life. That's not an issue with SSD, >> but multiple rebuilds is. That and simply keeping track of 80 partitions. > Suppose If I don't do the partitioning and get more SSDs to be able to create more raid5 thread - does my setup now sane ? No, because you're not addressing an actual workload problem, but merely playing with what-ifs. > Only reason i partitioned insanely was because I dont have enough SSDs yet. > > suppose if I get 32 SSDs . Then What is normal practice : > 1) Have one raid5 drives out of 32 SSDs > or > 2) Have 8 raid5 drives each with 4 SSDs > > My partitioning was only a proof-of-concept test to prove that buying > more SSDs and launching several raid5 will increase write throughput > in kernel I am using (2.6.32) You didn't need to perform a proof of concept in order to confirm anything. All you had to do is google "md raid ssd". This issue has been well documented for quite some time, as well as workarounds, some of which I mentioned. "Normal practice" would be to explain your target workload, and then discuss storage options that meet the needs of that workload. If you had a workload that actually requires the performance equivalent of 32 SATA SSDs, you'd already be looking at a high end SAN controller or a handful of LSI's WarpDrive devices, and not wasting time playing what-ifs with md/RAID's parity personality limitations. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
