Thank you for your reply and for taking the time to explain the SMR background behavior. I understand your point and appreciate the advice regarding CMR drives for RAID systems.
However, I would like to clarify exactly why I am looking for the firmware update, because it is not simply about the background noise itself.
### What ZFS is and why it matters here
ZFS (Zettabyte File System) is an advanced, enterprise-grade file system and logical volume manager originally developed by Sun Microsystems and now maintained as OpenZFS. It is used in TrueNAS, FreeNAS, Proxmox, and many other NAS/server platforms. ZFS is not a traditional RAID like a hardware RAID controller — it is a software-defined storage stack that handles data integrity, checksumming, self-healing, snapshotting, and RAID-like redundancy (called RAIDZ) entirely at the software level.
ZFS is specifically designed to detect and correct silent data corruption, which is exactly why it is used in professional and semi-professional NAS storage environments.
### Why the firmware matters specifically for ZFS
The issue I am referring to is not just background noise or normal SMR housekeeping. The firmware version **82.00A82** on WD60EFAX drives has a **confirmed and documented bug** that causes the drives to behave incorrectly under ZFS workloads, specifically during **resilvering** (which is ZFS's equivalent of a RAID rebuild after a drive event).
The confirmed effects are:
- Drives cause **false resilvering notifications** with no actual data event
- Under sustained load, drives produce **IDNF errors**
- Drives can be **dropped from the ZFS vdev/pool** (effectively ejected from the array)
- In worst case: **data loss or pool corruption**
This is not about using SMR in RAID in the traditional sense. ZFS handles SMR differently than hardware RAID, but even ZFS cannot work around a firmware-level bug that causes the drive to respond incorrectly to read/write commands during rebuild operations.
This has been confirmed by iXsystems (the company behind TrueNAS) themselves, as well as the OpenZFS development team.
### Sources confirming the firmware bug
**TrueNAS Forum – WD Red DM-SMR ZFS Issue:**
https://www.truenas.com/community/threa ... ame.84436/https://www.truenas.com/community/threa ... ame.85562/**Reddit – iXsystems confirmed ZFS Firmware Issue:**
https://www.reddit.com/r/DataHoarder/co ... th_wd_red/https://www.reddit.com/r/DataHoarder/co ... th_wd_red/**ServeTheHome – WD Red SMR Firmware 82.00A82 Failed State (detailed test):**
https://www.servethehome.com/wd-red-smr ... d-red-smr/https://www.servethehome.com/wd-red-smr ... red-smr/2/**GitHub – OpenZFS Bug Report: WD WDx0EFAX unable to resilver:**
https://github.com/openzfs/zfs/issues/10214https://github.com/openzfs/zfs/discussions/12973**WD Community – Firmware Update related problems:**
https://community.wd.com/t/drive-2-appe ... ate/271676https://community.wd.com/t/is-there-a-f ... -3tb/17646**Synology Forum – WD Red WD40EFAX problems:**
https://www.synoforum.com/threads/probl ... efax.5699/**QNAP Forum – WD Red issues and workarounds:**
https://forum.qnap.com/viewtopic.php?t=166476https://forum.qnap.com/viewtopic.php?t=150784### What firmware is needed and where
A newer firmware version such as **04.1VH0** is reported to resolve this specific bug behavior. Unfortunately, Western Digital has not made any official public update available on their website for this drive series. The update appears to be accessible only through:
- **HDDSurgery** (paid firmware database, approximately 1€ per model)
- **WD Support directly** after a support request
- Potentially NAS vendor channels (QNAP/Synology update paths)
This is exactly why I came here — I was hoping to find out whether you, with your experience and your firmware database, have seen a clean and confirmed update path for the WD60EFAX specifically, or whether such a patch exists in your Mega archive.
### Important note regarding my specific drives
I want to be very clear about my situation: I currently have **4 drives of this model** in total. Three of them are **brand new and have never been used** — they are completely empty with no data on them whatsoever. The fourth drive has only been powered on for approximately **177 hours** during occasional use, and it is also completely empty with no user data stored on it.
This means there is **no data at risk** on any of these drives at this point. My goal is to update the firmware **before** I start using them in a ZFS pool, precisely to avoid running into the known bug from the very beginning. I would rather fix this now on empty drives than deal with pool corruption or data loss later.
I fully agree with your warning about backup and brick risk — even though the drives are empty, I would still test the process on one drive first before applying anything to the others.
Thank you again for your time.
Soliver84