Короткий ответ

Ненулевой CKSUM в zpool status tank значит: ZFS прочитал блок, хеш не совпал. Это не NTFS dirty. Причины: диск, кабель/HBA, RAM без ECC / сбой ECC, редкий баг контроллера. Не делайте zpool replace первым шагом по самому большому числу в колонке, пока не сняли SMART и прирост. Запустите scrub в окне, чтобы пройти все данные, не только горячий кэш. Пока RAIDZ/mirror может восстанавливать — данные живы.

Hardware RAID под ZFS маскирует и врёт: checksum тогда часто «на всём vd0».

Симптомы и как отличить

Типичная картина:

  • tank ONLINE или DEGRADED, колонка CKSUM не нули;
  • TrueNAS: «Device ... has too many errors»;
  • приложения иногда EIO на одном файле;
  • SMART Pending = 0, CKSUM растёт — думайте о кабеле/RAM.
КартинаСкорее
CKSUM на одном vdev, SMART Pendingдиск
CKSUM на всех дисках сразуRAM, HBA, питание, общий кабель
Только READ/WRITE errors, CKSUM 0путь, диск offline
Hardware vd0 + ZFS checksumслой RAID, см. storcli

Отличие от SMART-алертов: SMART может молчать на редком corruption, ZFS нет.

Возможные причины

  1. Медиа HDD/SSD, silent corruption.
  2. SAS/SATA кабель, backplane, плохой HBA.
  3. Ошибка RAM (обязателен ECC на ZFS-сервере).
  4. Неправильный диск отдан двум подсистемам.
  5. Запись при резком power loss без PLP на slog (обычно не массовый CKSUM).
  6. Скретч: единичный CKSUM после reseat, дальше нули.

Диагностика

1. Снимок состояния

zpool status -v tank
zpool iostat -v tank

Запишите числа READ WRITE CKSUM по каждому устройству (wwn-...). Повторите через час без clear.

TrueNAS: то же в Shell, не только график.

2. Идентификация диска

ls -l /dev/disk/by-id/ | grep -E 'ata-|wwn-|nvme-'
smartctl -a /dev/disk/by-id/wwn-0x5000c500example

Сопоставьте имя в zpool status (часто gptid на CORE, wwn/ata на SCALE/Ubuntu).

3. RAM / ECC

sudo dmesg -T | grep -iE 'edac|ecc|mce|hardware error' | tail

MCE — не replace диска первым. memtest в окно, не на живом прод-NAS без плана.

4. Кабель

CRC в SMART (UDMA_CRC_Error_Count) на том же WWN + CKSUM — reseat/кабель, затем scrub. Не replace сразу.

5. Не ZFS на HBA

storcli /c0/vall show

Если tank на vd0, checksum ZFS = ошибка всего массива или кэша контроллера. Смотрите RAID и degraded.

Решение

Сценарий A. Скретч: +несколько CKSUM, потом тишина, SMART чистый

zpool scrub tank

Дождитесь конца. Если новых ошибок нет:

zpool status tank

После успешного scrub без новых проблем можно zpool clear tank чтобы сбросить алерт — после, не вместо расследования.

Сценарий B. Рост CKSUM + SMART media

Плановый replace по WWN. Backup. Не offlin'ьте единственный диск stripe.

Сценарий C. Все диски CKSUM

Железо общее: RAM, HBA, БП, expander. Scrub после замены подозреваемого. Replace всех дисков пачкой — дорогая ошибка.

Сценарий D. Permanent errors в файлах

После scrub ZFS укажет пути. Восстановите эти файлы из backup. zpool status -v не лечится rm вслепую без копии: вы потеряете и повреждённое, и шанс сравнить.

Сценарий E. Идёт production load

Scrub грузит пул. Ставьте в окно; на SCALE есть приоритет/лимиты в UI некоторых версий. Не параллельте ещё и полный backup dump на те же диски без нужды.

Счётчики CKSUM копятся с момента последнего zpool clear или импорта. Сравнивать абсолют «у соседа ноль, у нас 40» бессмысленно без даты clear. В тикете: числа до scrub, после scrub, прирост за сутки.

На NVMe checksum при идеальном SMART чаще путь PCIe или питание, чем сыпется NAND, но media_errors в nvme smart-log это опровергнут. На HDD с HBA ZFS обычно честнее hardware RAID: CKSUM видно рано.

Не запускайте zpool scrub tank одновременно с полным zfs send: I/O встанет, SMB «умрёт», кто-нибудь сделает reboot и scrub потеряет прогресс. Окно как у backup.

Как проверить, что проблема устранена

Scrub completed, 0 errors. Повторный status через сутки без прироста CKSUM. SMART без нового Pending. Приложение читает бывшие проблемные файлы (или они восстановлены). Алерт TrueNAS снят после clear если причина устранена.

Если не помогло

  • Scrub находит снова — статья scrub, решайте replace.
  • Ошибки только при scrub, не при работе: всё равно медиа/RAM, не игнорируйте.
  • FAULTED диск: сначала путь, потом replace.
  • Нет ECC в «файловом сервере из офисного ПК» — заложите RAM как причину №1.

Профилактика

  • ECC RAM на NAS01.
  • HBA IT-mode, не RAID кэш под ZFS.
  • Регулярный scrub (TrueNAS Scrub Task, Ubuntu zpool scrub по systemd timer).
  • Мониторинг CKSUM != 0.
  • Кабели SAS с запасом, не consumer SATA в куче.
  • Backup вне пула.

Если CKSUM появился сразу после замены кабеля и больше не растёт, не назначайте диск в RMA «для галочки»: вы тратите запасной и оставляете плохой backplane. Наблюдение 72 часа плюс повторный scrub — дешевле ложного replace, если SMART чистый и ECC RAM без MCE.

Обратное: «подождём, вдруг само» на растущем CKSUM одного WWN при живом RAIDZ1 — это ставка на второй отказ во время будущего resilver. Тогда replace не ждёт идеального окна в следующем квартале.

FAQ

zpool clear маскирует проблему?

Да, если делать до ремонта. Это сброс счётчиков.

Checksum errors на slog?

SLOG потеря при crash — вопрос транзакций, не классический CKSUM data. Смотрите отдельные устройства в status.

Можно ли scrub на 95% заполненном пуле?

Можно, будет медленно и больно для SMB. Лучше место + окно.

Ubuntu и TrueNAS разные цифры?

Разный uptime/clear. Сравнивайте прирост.

RAIDZ1 и один диск с CKSUM — срочность?

Высокая: нет запаса на второй отказ во время replace. Планируйте сразу.