The company iXsystems, which develops the FreeNAS project, has reported serious compatibility issues with ZFS and some new WD Red hard drives produced by Western Digital using SMR (Shingled Magnetic Recording) technology. In the worst-case scenario, using ZFS on problematic drives can lead to data loss.
Problems occur with WD Red drives ranging from 2 to 6 TB, released since 2018, which utilize recording technology (Device-Managed Shingled Magnetic Recording) and with the EFAX tag (for CMR drives, the identifier EFRX is used). Western Digital in its blog that WD Red SMR drives are intended for use in NAS for home and small businesses, where no more than 8 drives are installed, and the workload is around 180 TB per year, typical for backup and file sharing. The previous generation of WD Red drives and models with capacities of 8 TB and above, as well as drives from the WD Red Pro, WD Gold, and WD Ultrastar lines, continue to be produced based on CMR (Conventional Magnetic Recording) technology and do not pose issues with ZFS.
The essence of SMR technology involves using a magnetic head that is wider than the track width, resulting in partial overlap when writing to adjacent tracks, meaning any rewrite necessitates re-recording the entire group of tracks. To optimize operations with such drives, is used — the storage space is divided into zones, comprising groups of blocks or sectors, where only sequential data addition is allowed with the entire group of blocks being updated. Generally, SMR drives are more efficient in terms of power consumption, are more affordably priced, and show performance gains when sequentially writing data, but they lag behind in performing random write operations, including operations such as rebuilding storage arrays.
DM-SMR implies that zoning and data distribution operations are managed by the disk controller, and to the system, such a disk appears as a classic hard drive that does not require separate manipulation. DM-SMR employs indirect logical block addressing (LBA), similar to logical addressing in SSDs. After each random write operation, a background garbage collection operation needs to be performed, leading to unpredictable performance fluctuations. The system may attempt to apply optimizations to such disks, believing that data will be written to a specified sector, but the information provided by the controller determines only the logical structure, and in practice, the controller will use its algorithms during data distribution, taking into account previously placed data. Therefore, it is recommended to perform a reset operation to restore DM-SMR disks in a ZFS pool to their original state before use.
The company Western Digital is involved in analyzing the conditions under which problems arise, working alongside iXsystems to find a solution and prepare a firmware update. Before publishing findings on problem resolution, the drives with the new firmware are planned to be tested in high-load storage environments with FreeNAS 11.3 and TrueNAS CORE 12.0. It is claimed that due to the different interpretations of SMR by various manufacturers, some types of SMR disks do not have issues with ZFS; however, iXsystems' testing focuses solely on verifying WD Red disks based on DM-SMR technology. requires further investigation.
Currently, issues with ZFS have been demonstrated and replicated in tests for at least WD Red 4TB WD40EFAX drives with firmware 82.00A82 and a failure state under high write load, for example, during the rebuilding of the storage after adding a new drive to the array (resilvering). It is assumed that the problem also manifests in other WD Red models with the same firmware. When the issue occurs, the disk begins to return the error code IDNF (Sector ID Not Found) and becomes unusable, which is treated in ZFS as a disk failure and may lead to data loss on the disk. In the event of multiple disk failures, data in the vdev or pool may be lost. It is noted that the mentioned failures occur quite rarely — out of about a thousand sold FreeNAS Mini systems that were equipped with problematic disks, the issue has surfaced in operational conditions only once.
Source: opennet.ru
