Re: Update to Project_ideas wiki page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bart Noordervliet wrote:
On Wed, Nov 17, 2010 at 19:07, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
Since BTRFS is already doing some relatively radical things, I would like to
suggest that RAID5 and RAID6 be deemed obsolete. RAID5 isn't safely usable
for arrays bigger than about 5TB with disks that have a specified error rate
of 10^-14. RAID6 pushes that problem a little further away, but in the
longer term, I would argue that RAID (n+m) would work best. We specify that
of (n+m) disks in the array, we want n data disks and m redundancy disks. If
this is implemented in a generic way, then there won't be a need to
implement additional RAID modes later.

I presume you're talking about the uncaught read errors that makes
many people avoid RAID5. Btrfs actually enables us to use it with
confidence again, since using checksums it's able to detect these
errors and prevent corruption of the array. So to the contrary, I see
a lot of potential for parity-based redundancy in combination with
btrfs.

No. What I'm talking about the the probability of finding an error during the process of rebuilding a degraded array. With a 6TB (usable) array and disks with 10^-14 error rate, the probability of getting an unrecoverable read error exceeds 50%. n+1 RAID isn't fit for use with the current generation of drives where n > 1-5TB depending on how important your data and downtime are and how good your backups are.

And I don't put much stock in the manufacturer figures, either, so assume that 10^-14 is optimistic of it is reported. On high capacity drives (especially 1TB Seagates, both 3 and 4 platter variants) I am certainly seeing a higher error rate than that on a significant fraction of the disks.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux