“RAID-X” — Consumer grade extendable RAID — Did someone invent this yet? / Request for feedback
Upgrading and maintaining a home RAID installation is kind of a bitch — just saying. Especially if you’re cheap like me, and you have a Franken-RAID.
My current server has 4 striped sets of paired drives — none of the pairs is the same size as any of the other — my server had 8 bays, just I would just buy two drives in pair when I needed to upgrade — a new controller card if needed — create them as a new striped set — boot into windows — and expand the volume across the new set.
That worked great for a while — but Windows doesn’t allow you to span a volume across external drives (if the removable bit is set to true, the options are grayed out — if you do it while they’re internal, and then move them to external, it just pretends the drives are unformatted and shows them as RAW, it’s super silly…) — and also buying them in pairs is a bit expensive sometimes ($200 to add instead of $100…) — and… ZERO MOTHER-FUCKING REDUNDANCY… I mean… it’s worked great for like 6+ years now… and I’ve got 7 TB of space… but every now and then, I worry a little — you know? I mean crap, re-downloading all of that porn will take FOREVER.
So, RAID-5, right? — but then all the drives have to be matched size… also, I have no experience with RAID 5 — can you just add another drive to the mix willy-nilly and it works? — or do you have to reinitialize the whole array? (Can you reinitialize it after you add the drive, and not loose all your data? Is there a way to do this? And then… you’re limited by the number of ports on a single RAID card, no? So every time other time you upgrade you need a new card, that sounds like it would get very-expensive, very quickly…)
So, let’s take a step back — shouldn’t somebody have solved this problem by now? — Maybe a Linux soft-RAID driver that just lets you throw whatever you want at it, and it figures out the best, and most redundant config for your drives, and makes everything just work? And tells you when one failed and then you just go replace it, and everything’s happy? Am I dreaming?
Before the nay-sayers start claiming it can’t work — The problem — from an algorithm POV — doesn’t seem that hard to solve; here, I’ll walk you through how one implementation could possibly work (it was just right off my head, so it’s probably not even the most efficient):
For nostalgic purposes — and also just for the heck of working with smaller, more text-book-like, numbers — let’s say we’re building a RAID with 60 GB, and 80 GB drives (it’ll be fun!).
Let’s ignore the R part of RAID — just for a moment (we’ll factor it back in at the end — but for the sake of not putting the cart before the horse, let’s factor it out for now):
Each of these drives — 60 GB, and 80 GB — have many sizes that they can divide by evenly — for the sake of simplicity let’s say 20 GB for now (in a real implementation, you would use a smaller size, between 512 MB, and 2 GB, I think — just because, the drives will never match up so evenly — but let’s say they do — for simplicity sake, and that they can all be divided evenly by 20 GB…).
That means, we can treat the 60 GB drives like 3 LOGICAL 20 GB drives, and the 80 GB drives like 4 of them, etc, etc. — So — we can stripe those together — without parity (because it wouldn’t make any sense, right?) — so far, not a lot gained over a spanned configuration — sometimes, you might get an IO speed boost — but not always — and the processor hit would kind of suck — but we did it — we combined the drives together for their total size — albeit in a way that was kind of dumb — but it allows us to factor redundancy back in quite easily now…
So how do we do that? — Well, stick with me for a moment, before shaking your head — but you’ve heard of RAID 5, yes? — It uses N+1 drives of equal size — and you can get the full storage space of N (the storage distributed across the N+1 drives evenly, along with a parity that is also distributed across the drives evenly). — If one drive fails — it can be reconstructed.
But that’s no good for us, because if one of the PHYSICAL 60 GB drives fails, we lose 3 LOGICAL drives! and god forbid the 80 GB drive would fail — that would be like losing 4 LOGICAL drives!
*dun-duh-da-dun!* Enter RAID 6. It requires N+2 matched drives (and makes N drives of space usable with 2x the distributed parity) — allowing up to two drives that can fail, and still be rebuilt…
So, what about N+3, and N+4? Yep, 3 and 4 drives can fail… Nice, right? (I mean, it’s not commonly done — and I don’t even know if there are implementations that support this — but I see no reason why it couldn’t be done — do you?).
So, let’s say we have a RAID-X setup of 3 PHYSICAL drives — two 60 GBs, and one 80 GB. — let’s split that into 20 GB chunks and pretend it’s really ten 20 GB LOGICAL drives (60 + 60 + 80 = 200. 200 / 20 = 10).
To be fault tolerant for failures of the 60 GB drives you would need a RAID 6 setup of at least N+3 — to be fault tolerant for the 80 GB you would need a setup of N+4 — (so 60 or 80 GB of the whole, respectively, depending on how much you felt like gambling) — so with three drives, you would have 120 (or 140 if you wanted to gamble) of fault-tolerant storage.
I know what you’re thinking — for true fault tolerance, the N+4 setup — we see only 120 GB of space — and that’s the same for if we did a regular RAID-5 and just used three 60 GB drives. — That’s true. But don’t forget about scaling. Let’s say that we add another 80 GB drive into the mix now (because it’s a year later and we want to upgrade a little — and bigger drives are cheaper, right?) — So that makes: two 60 GBs and two 80 GBs — well — that 80 GB just goes right in — and we’re at 200 GB now (or if we didn’t expect the 80s to fail, and wanted to gamble a little, we could squeeze out 220 GB of storage from the array…) — versus with regular RAID 6 you would be looking at those like 60 GB drives (giving you only 180 GB of free storage) — and pretty soon you start adding in 100s — well now you need to be ready to support losing 5 drives (etc…) — but once that second 100 GB goes in, you start seeing the benefits…
Basically you lose the amount of storage as the biggest drive that you want to be safe against — if you only have one drive of that size, it might as well be the next smaller size down, as far as how much good it does you for storage — however — once you add another drive in that’s the same size (or bigger) — you get that space back. — You could also do other things, as aforementioned, you could gamble and only be tolerant for the 60 GB. Or say you had a 10 drive setup — five 60s, and five 80s — you could be tolerant against two drives failing — you could be decide to be tolerant for 80 GBs for the first drive (which would handle any 60, or 80 GB drive failing) — and 60 GB for the second drive (so if two drives fail, and at least one of them was a 60 GB drive, you’re all-set, but only if they were both 80s would you actually lose everything).
There’s probably a way to be even more efficient, and redundant as far a theoretical approaches go, but this was just the simplest, off-the-top-of-my-head solution.
It seems like you could probably do the equivalent of this, manually, with existing Linux soft-RAID Drivers — but every time you added a bigger drive, you’d have to reinitialize the whole array, and loose all your files (because it wouldn’t even be the same level of RAID anymore — you would go from N+3 to N+4, or N+5, etc…, or the evenly divisible amount might change slightly, so the whole stripe nature would change) — also you’d have to figure out every upgrade by hand — backup all your data, rebuild — do it all again — and that would just be a silly waste of time to do all that by hand every time — not to mention all of the backup medium you’d need…
So, is there something that can manage all of the above automatically — and handle the upgrading — reinitialization — repairing, etc. of such? — Does this already exist? — Or do I have to go learn how to write drivers / modules for Linux now?
Also — is there an exiting way to do background drive health checks (maybe something halfway between SMART and CHKDSK full surface scan) without taking the whole drive array down? (I mean, because, there should be — assuming none of the drives are in the DEAD state, you could theoretically operate without at least one whole drive for most setups — so maybe the system could always be systematically testing itself — never one drive all at once — but maybe one or more logical 512 MB block at a time (one for each drive that’s not currently IO bound) — and based on some schedule — you would know how often the full set of drives was checked — i.e. if a full surface scan takes 80 days, you would know that within ~120 days (of moderate usage) the whole set had the equivalent of a surface scan performed on it… no?)