Do not put shingled drives in a parity RAID array. They work normally until a rebuild, and then they can extend it from hours into days or drop out of the array altogether, during the exact window when your data has no redundancy.
Shingled recording overlaps data tracks like roof tiles to raise density. Reading is unaffected. Writing is affected when the drive has to modify data underneath an existing track, because the tracks laid over it may have to be rewritten too. That penalty is invisible for sequential work and severe for sustained random writing, which is what a rebuild or a resilver actually is.
Shingled drives manage this with a conventionally-recorded staging zone. Incoming writes land there quickly, and the drive reorganises them into the shingled region during idle time. It is a good design for the workloads these drives are sold for, and it is why they perform normally in ordinary use.
A rebuild breaks both halves of that design. The volume of writing exceeds the staging zone many times over, and there is no idle time to reorganise because the array is writing continuously until the rebuild completes. The drive ends up doing read-modify-write cycles across the shingled region while the controller keeps feeding it data.
The result is a rebuild that can run many times longer than the array expects. In the worse case the controller's timeout is exceeded and the drive is marked failed and ejected, which on a single-parity array means the rebuild has now failed with no redundancy remaining.
A rebuild is the one operation where an array has spent its safety margin. In single parity, one drive is already gone and a second failure destroys the pool. In double parity you have one failure left in hand.
Everything about a rebuild also increases the chance of a second failure. Every remaining drive is read end to end, often for the first time in years, under sustained load, at elevated temperature, and the drives are typically the same age and from the same batch as the one that just failed.
That is why extending the rebuild window is more serious than it sounds. You are not just waiting longer; you are holding the array in its most vulnerable state for longer, while doing the thing most likely to expose another weak drive.
Check part numbers before buying, not product names. Our resolver answers from the manufacturer's document for the exact model, and the live table below shows conventionally-recorded drives in stock now.
If you have a shingled drive in an array already, the right move is usually patience rather than urgency. Confirm your backups, avoid triggering an unnecessary resilver, and swap the drive at a moment of your choosing. Forcing a rebuild today to remove a drive that has not failed creates the exact risk you are trying to avoid.
For a new build, a conventionally-recorded drive removes the question permanently, and the NAS-rated lines from all three manufacturers are conventional throughout. That is worth more than the price difference for most people.
| Drive | Capacity | Recording | $/TB | Price | |
|---|---|---|---|---|---|
| 695842-001 4TB SAS 6G | 4TB | CMR | $14.00 | $56 | Buy |
| HUS726040ALS210 4TB SAS 12G | 4TB | CMR | $18.68 | $75 | Buy |
| 695842-001 4TB SAS 6G LFF | 4TB | CMR | $20.56 | $82 | Buy |
| 012GYY 4TB SAS 6G Renewed | 4TB | CMR | $21.25 | $85 | Buy |
| DRMYH Compellent 4TB NL SAS Renewed | 4TB | CMR | $22.50 | $90 | Buy |
Because shingled drives absorb writes into a conventional staging zone and reorganise during idle time. A rebuild exceeds the staging zone and eliminates the idle time, so the drive falls back to its slow path and stays there for the duration.
Yes. If the drive stops responding within the controller's timeout while it is reorganising, the controller can mark it failed and eject it. On a single-parity array during a rebuild that leaves you with a failed rebuild and no redundancy.
Milder but still not advisable. A mirror rebuild is a full sequential copy rather than a parity reconstruction, which suits shingled drives better than striped parity does, but you are still writing an entire drive continuously with no idle time.
No, and resilvering is arguably harder on shingled drives than a traditional rebuild because it can be more random in its access pattern. ZFS also has no special accommodation for the drive's reorganisation behaviour, so the timeout risk remains.