>Let's take a current datasheet [1]

Of a high profile and high quality enterprise disk, unlikely to appear in 99% of RAID setups. Congratulations.

Most RAID setups in the wild consist of low quality enterprise or even desktop platters, high quality setups are rare and expensive.

Esp. considering that lots of consumers have a NAS or MyCloud/eqv. at home and SMB doesn't buy those harddrives either, I don't think this is a valid comparison.

[https://www.seagate.com/files/www-content/product-content/na...]

[https://www.seagate.com/staticfiles/docs/pdf/datasheet/disc/...]

These drives here have an OOM higher error rate on the data sheet and they're still not very common, plus the error rate is given in bits here, shaving of 3 or 5 OOM again, calculating it out gives you an bad bit every 12 TB or so. Depending on how your RAID works, this can ruin the entire stripe or the sector it gets the hit on.

12TB isn't a lot and there is a good probability that a 3x4TB RAID5 array will hit such an error and a 3x2TB RAID5 has a 50/50 chance of having it during a rebuild.

>I'm not convinced that "waste" can ever depend on use case

It definitely can. Consider the use case of "office documents" vs "high performance video storage". With office documents a high throughput is not needed so we can reduce storage costs by using a RAID5 or 6 depending on array size. Video storage for example for CCTV requires more throughput an a RAID10 will give you better performance at some lost effective storage.

You can of course put your office documents on a RAID10 but that is the wasted space. It is not necessary to maximize the RAID performance and the low storage needed for office documents means you can use RAID5 on small arrays fairly safely, RAID6 if you need more.

Waste is a matter of efficiency in all domains, in this case means picking the RAID level that maximizes storage efficiency, performance goals met and safety as best as possible. Picking one that trades off one for the other is waste or even dangerous.

>My assertion is that best practice dictates frequent failover.

I don't think I ever met a sysadmin that insistent frequent failover due to failure is considered best practise. Regular testing yes, regular failure, no. Failure is expensive, testing not.

>You still haven't actually quantified the risk. "Unlucky" and "possible" are too hand-wavy to engineer around.

They're not really, plus you can easily quantify risks as you have done using datasheets. Though the moment your array isn't a singular batch of exactly the same harddrive these estimations become a lot harder.

You don't need to exactly quantify the risk, it is sufficient to know the margins of the risk or even if you are going into the margins of the risk, ie a risk model.

I don't need to know the exact and perfect probability of a read error on the array, I need to know if the array is likely to experience one (with likely being >1% or any other >X% during a rebuild or during normal operation). This question is more easily answered and doesn't require more than estimations.

This trades cost efficiency for safety margins meaning that an array has a comfortably low actualized risk of failing. That is what I consider actual engineering there.