The Western Digital Red Pro 10TB WD101KFBX model does not appear to be in the smartdb. Specifically, attribute 22 is unidentified but believed to be the helium level.

At line 4304 of drivedb.h at changeset 4909, there seem to be no custom attributes defined for Western Digital Red Pro drives.

From Western Digital's own press release, the 10TB version of the Red Pro is helium-filled. ​https://www.westerndigital.com/company/newsroom/press-releases/2017/2017-05-17-western-digital-expands-wd-red-and-wd-red-pro-nas-drives-with-10tb

I ran sudo /usr/sbin/update-smart-drivedb to ensure I have the freshest database version available. I am running smartmontools-6.6-5.fc29.x86_64 on Fedora 29.

Spec Sheet: ​https://www.wd.com/content/dam/wdc/website/downloadable_assets/eng/spec_data_sheet/2879-800022.pdf

Attached is the output (with serial number redacted) from smartctl after running a short SMART test, as requested by the FAQ. Or in other words, the output of running sudo smartctl -q noserial -x -d megaraid,34 /dev/sdc > smartctl-WDC-WD101KFBX-68R56N0.txt.

Noteworthy mention, I am running the drive from an Intel RS25DB080 RAID controller (identical PCB to the LSI SAS 2208) with the latest firmware (3.460.115-6465). The MegaRAID drivers are installed and up-to-date (storcli-1.21.12-1.noarch).

The default error correction timeouts of many HDDs cause data loss or corruption (so long or disabled that the controller hard resets the drives instead of only marking single blocks as bad). And the smartctl utility is the place to adjust the "scterc" timeouts of HDDs.

Please ship the provided scripts and default udev rule with the smartmontools package, so that they try to configure safe timeouts, depending on the drives capabilities, usage and configuration.

The problem with mismatching default timeouts surfaced through repeated reports about drives being droped from raid arrays, and about a high rate of unrecoverable errors occuring during raid-reconstruction, on the linux-raid mailinglist, but the problem is not limited to redundant disk setups. Many experienced "disk failures" are probably just failures due to mismatched recovery timeout settings.

(The scripts have been posted upstream without response, but it is still a distro resposibility to ensure that installations will have safe defaults. Note that the provided udev rules specific to mdadm are only to be included in the mdadm package.)

RATIONALE

The error recovery (ERC) time of a drive *must* be shorter than the controller timeout.

Otherwise read errors will cause controller resets, leading to direct data loss or, if it is a redundant disk, loss of redundancy and a very high probability of another read error and data loss when re-establishing the redundancy.

If a drive does not support adjusting its ERC timeout, the controller timeout must be increased above the drive's maximal error recovery time. If you don't want that kind of long device timeout, you should look for a drive with SCT ERC timeout support. (smartctl -l scterc /dev/...)

The files are attached at: ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780162

See attachment.