Let's face it, most of us buy NAS drives on faith. I certainly did, and every hard drive in my NAS is a NAS or enterprise model because that's what you're told to put in one. Ask why, and the answer often comes back as a single firmware timeout that determines how long a drive keeps fighting a bad sector before it gives up. It's not the only specification you should pay attention to, but it's an important one for when using RAID.
That timeout goes by three names: TLER on WD drives, ERC on Seagate, and CCTL on Samsung and Hitachi. It's been a spec-sheet bullet since WD's RE4 server drive advertised it in 2009, and it's a big reason people tell you to buy the best hard drives for NAS instead of whatever's cheapest. So I asked my own drives what they were set to, and the number wasn't the one I expected.
Picture a drive hitting a sector it can't read cleanly. A desktop drive will keep rereading it, adjusting and retrying, because it assumes it holds the only copy of your data and giving up means losing it. That's the right call for a lone drive in a PC, and it's why desktop drives have traditionally shipped with the limit switched off.
In an array, that stubbornness backfires. Once you set up RAID in a NAS, another copy of that data sits on a different drive, and the array would rather rebuild the sector from there than wait. Hardware RAID controllers drop a drive that stalls past their command timeout, while Linux waits 30 seconds by default before resetting a drive that's gone quiet. A time-limited drive gives up early, reports the error, and lets the array fix it, saving you time and your data.
sudo smartctl -l scterc /dev/sde remembering that smartctl counts in tenths of a second:
sudo smartctl -l scterc,70,70 /dev/sde
