I have a pool of 6x 8TB drives in 3 mirrors. I received an alert that two of the drives are formatted with DIF (I believe this is the second alert I’ve received for this, but both fairly recent).
Critical
Disk(s): sdf, sda are formatted with Data Integrity Feature (DIF) which is unsupported.
2025-08-23 07:51:27 (America/Toronto)
Searching around a bit it seems like this would typically prevent these disks being added to a pool in the first place. The pool was originally created a few years ago on Core, maybe those checks weren’t present at the time?
I see that the solution is to reformat without DIF, which isn’t ideal since the disks are in use. I do have a spare and could replace each and reformat one at at a time if necessary. The two drives are in different mirrors, and all important data is backed up elsewhere.
Do I need to address this? As I said the pool has been working well for several years in its current state.
And in light of that, how critical is this critical alert? Is keeping DIF on more likely to cause issues than the strain of two full resilvers of 8TB drives?
The DIF, (Data Integrity Field), for disks is used by hardware RAID and disk arrays to add extra hash / checksum to sectors that is written by the host, (disk driver? disk controller?), all the way to the media. This allows the host to verify that the sector was not damaged.
In the past for 512 byte sectors, this was an 8 byte addition, making the sector 520 bytes long. Naturally this required low level format changes on Hard Disks, or extra cells for flash memory storage.
Some disk device drivers understand DIF and can use it. Others simple can’t even use such disks.
There is no certainty that disks using DIF formatting will be usable in the future. If it works now, it basically is your choice to reformat or not.
One of the goals of ZFS was to use commodity disks, like those without DIF formatting. Further, ZFS uses much larger checksums to detect errors. However, ZFS uses larger blocks, that can span several disk sectors and maybe multiple disks.
That makes sense, and thanks for the extra context!
So if I’m not wrong DIF in this case would be implemented through a kernel driver - in that case would the main risk be that a future Debian / Linux kernel release removes driver support?
Or is there a larger risk due to possible conflicts between the ZFS and DIF integrity checks?
Correct. If you change system boards, and end up using different drive ports, those ports may not support DIF. Or Linux could remove DIF or break the feature.
I am not aware of any problem between ZFS & DIF.
In the past, we have had people wanting to use DIF in ZFS, or full file checksums for that added extra protection. However, unless those features are mainlined and supported, the problem becomes that they get less used or tested.
