3 ms·

The raid rebuild speed with SMR drivers is scary long, see https://www.servethehome.com/wd-red-smr-vs-cmr-tested-avoid-red-smr/2/ https://www.servethehome.com/

• Filligree 6y ago
  Which is strange, honestly. RAID rebuild is a streaming write from one end of the disk to the other; something which should be the ideal case for SMR, if the firmware catches on.
  • basilgohar 6y ago
    That's only the case in the first write. Rewritten blocks suffer from severe write amplification in SMR drives due to much larger segments needing to be written even for small changes. Rather than ideal, a rebuild is actually the worst case scenario as the RAID may detect the drive as unresponsive as it scrambles to catch up and thus gets dropped, exacerbating the problem for the other drives in the array. This is HL2 Resonance Cascade bad.
  • rini17 6y ago
    If it is software raid (like ZFS or Btrfs), the writes are random. Plus, it's not clear SMR can be made to accept heavy write load even when the load was predictable.
  • dathinab 6y ago
    The iX systems blog linked above implies that: - not all SMR drives seem to cause problems - rebuilding on a non-fresh/cleard hard drive can have negative performance implications due to how SMR works So my guess is that it's a problem with the firmware which can potentially be fixed. After which they could be used in a NAS, just aren't necessary as far as you might think. So I guess it's probably not looking too good for the lawsuites chances to cause much yield/discount.
• JustAPerson 6y ago
  The notable quote: > That 9 day and almost 14-hour rebuild means that using the WD Red 4TB SMR drive inadvertently in an array would lead to your data being vulnerable for around 9 days longer than the WD Red 4TB CMR drive or Seagate IronWolf. The other 4TB drives they compared against completed in around 15 hours, meaning the SMR drive could potentially take 14x longer to rebuild a RAID.