On 05/09/20 22:47, Brian Allen Vanderburg II wrote: > The idea is actually to be able to use more than two disks, like raid 5 > or raid 6, except with parity on their own disks instead of distributed > across disks, and data kept own their own disks as well. I've used > SnapRaid a bit and was just making some changes to my own setup when I > got the idea as to why something similar can't be done in block device > level, but keeping one of the advantages of SnapRaid-like systems which > is if any data disk is lost beyond recovery, then only the data on that > data disk is lost due to the fact that the data on the other data disks > are still their own complete filesystem, and providing real-time updates > to the parity data. I doubt I understand what you're getting at, but this is sounding a bit like raid-4, if you have data disk(s) and a separate parity disk. People don't use raid 4 because it has a nasty performance hit. Personally, I'm looking at something like raid-61 as a project. That would let you survive four disk failures ... Also, one of the biggest problems when a disk fails and you have to replace it is that, at present, with nearly all raid levels even if you have lots of disks, rebuilding a failed disk is pretty much guaranteed to hammer just one or two surviving disks, pushing them into failure if they're at all dodgy. I'm also looking at finding some randomisation algorithm that will smear the blocks out across all the disks, so that rebuilding one disk spreads the load evenly across all disks. At the end of the day, if you think what you're doing is a good idea, scratch that itch, bounce stuff off here (and the kernel newbies list if you're not a kernel programmer yet), and see how it goes. Personally, I don't think it'll fly, but I'm sure people here would say the same about some of my pet ideas too. Give it a go! Cheers, Wol
