How likely is a read error during a RAID rebuild, and why do the datasheet math and the field data disagree?

The answer. Read literally, the printed rates make a full-capacity rebuild of a large single-parity array look close to hopeless at 1 in 10^14 (99.2% for five 12 TB survivors, derived) and a coin toss at 1 in 10^15 (55.1% for five 20 TB survivors, derived). Those numbers come from the spec treated as a steady per-bit rate. The two field studies opened here show that real latent errors are not steady: they hit few disks, and then hit them in bursts.

What the field data change. In the 2007 study 3.45% of disks developed any latent sector error in 32 months, yet a disk with one error was 37 times as likely (0.671 against 0.018, derived ratio) to get another soon after. The 2010 analysis of the same data found that 55 to 85% of affected drives had all their errors in one 2-week window and that a geometric or Poisson model fit poorly. A per-bit Poisson model therefore tends to spread errors thinly over every disk, whereas the field data put many errors on a few disks, so the datasheet math says little about whether the next rebuild will meet one. It does not say the risk is small: the study counted nearline disks at 8.5% over 32 months, and a read error during a single-parity rebuild is a data-loss event.

Why this does not simply cancel out. Both papers also show what helps. More than 60% of errors in the NetApp systems were found by media scrubbing, so an error that scrubbing found and repaired before a disk failed is not there to hit the rebuild; a disk that has recently logged errors is the one to treat carefully, since errors arrive within a month of the first for 54.8% of nearline and 62.0% of enterprise error disks. The 2007 paper's own repair suggestion was to accelerate rebuilds when the survivors are over a year old or have logged an error in the last 1,000 minutes.

What ZFS adds, and what it cannot. A RAIDZ resilver is a healing resilver: the OpenZFS documentation says sequential reconstruction is not supported for raidz, so the resilver verifies each block's checksum as it reads and repairs on the spot, at the cost of a slower, more random I/O pattern. Redundancy is not restored until it finishes, so the risk window is longer than a sequential rebuild would be. A mirror or dRAID can rebuild sequentially, faster, but without checksum verification until the automatic scrub completes. Whether a given pool would meet an unrecoverable read at all depends on how much of it holds data: the source comment says sequential reconstruction resilvers only allocated capacity, so the 90.9% row in the math table is an assumed half-full case, not a property of any particular pool.

What not to conclude. None of the sources opened here measures how often rebuilds fail. A pessimistic reading of the spec (nearly every large single-parity rebuild hits an error) is not supported by the field data, and an optimistic reading (3.45% means a rebuild is nearly always safe) is not supported either, because the rate is for a 32-month lifetime on old drives and depends strongly on model, age and capacity: the 2007 paper reports the fraction of affected disks rising with capacity within a family, yet no consistent rise in errors per gigabyte. Datasheet and field figures are different quantities; compare them only with those definitions in hand.