# Separate TrueNAS SMART polling from ZFS failure detection > TrueNAS 25.10 and later combines ninety-minute SMART polling with ZFS I/O failure detection; identify which observation triggered a drive-health investigation. - Canonical URL: https://update.dsesecurity.com/updates/separate-truenas-smart-polling-from-zfs-failure-detection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:04+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know TrueNAS 25.10 and later combines ninety-minute SMART polling with ZFS I/O failure detection; identify which observation triggered a drive-health investigation. ## Potentially affected TrueNAS 25.10-and-later Drive Health Management as documented; confirm the installed release, drive identity and actual alert source. ## DSE recommendation DSE recommends preserving the alert type and observation time before choosing additional diagnostics or a drive-replacement response. ## Article Bottom line: Identify whether a drive-health concern came from a polled attribute, a ZFS event or a temperature alert before choosing the next action. Keep the observation time and affected device with the alert instead of reducing every condition to a generic disk-failed label. ## Source fact: what the authority says The [TrueNAS Drive Health Management guide](https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/disks/drivehealthmanagement/) describes middleware SMART polling every 90 minutes for TrueNAS 25.10 and later. It contrasts this with ZFS detecting a sudden failure when an active read or write operation returns an error. The guide lists SMART-stat, ZFS-event and temperature alert types, with the alert details identifying the disk and triggering attribute or event. Its manual-test discussion warns of significant LONG-test performance impact and recommends avoiding overlap with data-protection tasks such as snapshots and scrubs. ## What the source does not establish The documented layers do not guarantee advance warning for a particular device or prove that an alert identifies a replaceable hardware fault. This article does not recommend the guide’s deprecated test API. DSE keeps alert interpretation, any additional test and a replacement decision separately accountable. ## Applicability questions - What exact drive and installed release are in scope? - Which alert type, attribute or event triggered the investigation, and when was it observed? - What other storage activity or diagnostics are already running? - Who decides whether to investigate, contact support, schedule a test or prepare replacement? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends preserving the complete alert context before acknowledging or acting on it. Record the device identifier, reported type, value or event, time and current pool information. Keep the owner’s interpretation beside the original observation so a later reviewer can tell which part came from the platform and which part was an operational judgment. Use three proposed review records: a SMART attribute threshold, a ZFS I/O event and a temperature condition. Ask the responder to select the relevant diagnostic path for each without treating the records as interchangeable. For an exercise, use synthetic records or a supported safe test mechanism rather than attempting to induce damage in a live drive. If additional testing is justified, plan it around current data-protection activity and workload limits. Have the storage owner select the supported diagnostic method for the actual deployment and explain what finding would change the response. Keep a request for more evidence distinct from authorization to remove a drive, run a destructive utility or suppress a recurring alert. Keep the recorded time of the diagnostic observation separate from the time an operator received the notification. Ask which interval the available record actually describes. Avoid filling an unobserved interval with a claim that every drive condition was continuously checked. ## Verification and evidence Proposed verification: have another operator trace each review record to the affected device and explain its observation layer and timestamp. Check that the configured notification path reaches the intended responder using an approved test. Keep notification delivery evidence separate from the underlying diagnostic interpretation. For any authorized manual test, retain the method, device, start and completion observations, concurrent workload and actual result. Compare the findings with the owner’s decision criteria and document unresolved contradictions. Recheck the official guidance after a release change; do not preserve an obsolete testing workflow solely because an earlier rehearsal used it. ## Official references - [TrueNAS — Drive Health Management](https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/disks/drivehealthmanagement/) — official product documentation; confirm the installed release and configuration. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: TrueNAS — Drive Health Management - Authority: www.truenas.com - URL: https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/disks/drivehealthmanagement/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Separate TrueNAS SMART polling from ZFS failure detection,” DSE Security, https://update.dsesecurity.com/updates/separate-truenas-smart-polling-from-zfs-failure-detection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.