Right, I did hear about that lawsuit way back when, I just didn't know of these types of consequences. Very appreciated, especially the sources.
I really appreciate you linking studies about this topic, as finding this kind of research can be daunting. Those looks like really interesting reads.
Is this for hardware RAID controllers, or have you experience software RAID like LVM or ZFS exhibiting the same drop out behavior? I personally haven't but it be nice to look out for future drives.
Drive 1: A, Drive 2: 1/2 A, Drive 3: 2/2 A. Drive 2 + Drive 3 = Drive 1. Hmm that would only be one set of the party though. So you could also add 1/2 of A to Drive 1, and 2/2 to Drive 2 so that the parity on Drive 1 + Drive 2 = Drive 3. Which is extremely silly, and doesn't make a lot of sense to use in the real world.
Oh thanks for the tip! I've edited my comment to reflect the minimum of 4 drives for a RAID6 array.
I've not used RAID6 for a small array like that before so I didn't know it had a conventional lower limit. From the technical sense it doesn't have to have 4 drives, it just wouldn't make any sense to use it that way so I see why software wouldn't support such a use case.
Yes their failure rates are usually a bit higher, but usually less than the increase in rate from using more than one disk instead. A bit of math can be done using Backblaze's disk failure rate data to get a reasonable approximation of the overall risk of failure.
Exactly! RAID gives you the breathing room to react to the partial failure of the full RAID array disk. I appreciate your understanding.
Oh I thought there was some other CVE acronym I was unaware of. I don't think periodically git cloning a repo every few days would be something to worry about. Ever since the Yuzu take down I got in the habit of mirroring a bunch of repos that I'd be very sad to lose, just as a precaution, it probably won't matter, but it's a tiny peace of mind knowing I could at the very least compile it myself if it was lost.
Consider a scenario with a degraded RAID 1 array comprised of two 1.6 TB disks capable of transferring data at a sustained rate of 6 Gbps: you should be able to recover from a single disk failure in just over half an hour.
Repeat the same scenario with 32 TB members, now we’re looking at a twelve hour recovery - twelve hours of intensive activity that could push either of your drives over the edge. Increasing data density actually increases the risk of data loss.
The speed and method you use recover from data loss is not relevant to the discussion of how to handle drive failure. That varies wildly depending on your specific setup.
Finally, we say you shouldn’t think of RAID as a backup because the entire array could fail, not for the excruciatingly literal reasons you are attempting to convey. If you lose half of a two disk mirror set, you haven’t lost any data.
My premise is that reducing the number of drives reduces the risk of drive failure which could lead to data loss. RAID is not a backup, because it literally isn't. If you have two drives in RAID1 you have 1 set of your data. If you have 4 drives in RAID6 you have 1 set of your data. In both examples you have a single very durable drive, but you do not have a backup. A backup prevents data loss, RAID does not.
Think of it this way. You have a single very large drive, and you explicitly only use 1/2 of it. The other 1/2 of the drive becomes broken and you cannot read or write to it. The first 1/2 work perfectly fine, and fits all your data. Would you consider this drive functional, or failed? A RAID degradation is a warning to the user that a portion of the single drive is broken, and needs to be repaired. A RAID block device should always be treated as a single physical drive, with varying levels of durability and warning signs depending upon its configuration. It can't be a backup, because all its doing is delaying the eventual failure. Delaying a failure does not prevent the failure from happening, and does not help you when a failure occurs.
@meteokr
@community.adiquaints.moe