From d01c84c2bc85acf720a1d37ad5d0f4706c9cef0f Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 14:49:16 +0600 Subject: [PATCH] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 54 +++++++++++++++---- 1 file changed, 44 insertions(+), 10 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 1d31831a..c67f9783 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,8 +1,12 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 (финал: HGST упал, см. блок ниже) +> Обновлено: 2026-08-17 ночь (два КРИТИЧНО: HGST упал и сломан; RED_2TB вызывает kernel panic — см. раздел пулов) -## ⚠️⚠️ КРИТИЧНО: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB вызывает KERNEL PANIC (важнее HGST) + +См. раздел «Пулы TrueNAS» → блок «RED_2TB не импортируется — вызывает KERNEL PANIC». Это приоритет №1 — данные реально есть. Система в panic loop; рецепт: тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем import. + +## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения **2026-08-17 вечер.** HGST (HUH721212ALE600, сер. 8CKD08RE) **уронили на пол, будучи подключённым**. Развитие сценария (как происходило): @@ -135,21 +139,51 @@ lspci -k | grep -i sata - RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. -### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB НЕ заимпортирован +### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB не импортируется — вызывает KERNEL PANIC -После перетыкания дисков на материнке пул **RED_2TB НЕ поднялся автоматически**: `/sbin/zpool list` показывает только `boot-pool`, а `/sbin/zpool status RED_2TB` → `cannot open 'RED_2TB': no such pool`. +После перетыкания дисков на материнке пул **RED_2TB не поднялся автоматически**, и при попытке `zpool import -F` система упала в **kernel panic bootloop**: -**Это НЕ потеря данных.** Все члены пула физически на месте и видны системе (проверено 2026-08-17): +``` +panic - not syncing: zfs: adding existent segment to range tree + ZFS: space_map_load / metaslab_activate / zio_dva_allocate → zfs_panic_recover +``` + +**Что это:** повреждение space map (метаданных ZFS) пула — один и тот же блок учтён дважды / неконсистентное отображение. При обычном импорте ZFS званивает panic по-умолчанию. **Это не обязательно полная потеря данных**, но структура пула повреждена. + +**Триггер (вероятный):** диски-члены отвалились во время работы/перезагрузки при перетыкании, или один из членов имеет скрытую проблему в области метаданных. Члены пула при этом физически на месте: - `sda2` = WD2TB#1 (ata1) - `sdb2` = WD4TB (ata2) — буква сменилась с `sdc` на `sdb` - `sde2` = Seagate4TB (ata6) -Пул просто не заимпортировался, вероятно из-за смены букв устройств. **Что нужно сделать (порядок):** -1. TrueNAS WebUI → **Storage → Import Pool** → выбрать `RED_2TB`, импортировать. - - Альтернатива под root: `/sbin/zpool import RED_2TB` (truenas_admin НЕ может — `sudo` требует пароль; `zpool import` даёт `cannot discover pools: permission denied` без root). -2. После импорта проверить: `/sbin/zpool status RED_2TB` → все члены `ONLINE`, `READ WRITE CKSUM` = `0 0 0`. +**Сейчас система грузится В panic loop каждый раз** (автоимпорт RED_2TB валит ядро на старте). + +#### ✅ РЕЦЕПТ ВОССТАНОВЛЕНИЯ (подтверждён web-источниками, openzfs #15030 + треды TrueNAS) + +**Панику в ZFS можно превратить в warning тремя тюнабелями** (передача как параметров ядра в GRUB): + +1. **В загрузочном меню GRUB** (при старте держать Shift/ESC) выбрать ядро TrueNAS, нажать `e`, в строке с `linux`/`vmlinuz` добавить в конец: + ``` + zfs.zfs_recover=1 zfs.zil_replay_disable=1 + ``` + `Ctrl+X` загрузиться. Это даёт системе дойти до консоли/WebUI без паники (Panic→warning). + +2. **Под root импортировать пул аккуратно** (не форс-катастрофически с наскоку): + ```bash + /sbin/zpool import # какие пулы видит, без монтирования + /sbin/zpool import -n RED_2TB # dry-run — нужен ли -F и не падает ли + /sbin/zpool import -F RED_2TB # только если dry-run показал, что требуется -F + ``` + > В треде TrueNAS подтверждено: `zpool import -f -F -X` «не срабатывало», а с тюнабелями в GRUB + импортом — срабатывает. Сначала тюнабели, потом import. + +3. **После импорта:** `/sbin/zpool status RED_2TB` → оценить члена с ошибками. Снять важные данные с пула на другие диски при первой возможности (импорт `-F` + recover может ценой части изменений). Честно проверить RAM/ECC — в треде #31410 это был реальный фактор повреждения. + +> ⚠️ Пока пул не восстановлен, **НЕ запускать повторный автоимпорт/`-F` сипломи** — каждый заход углубляет риск. Сначала тюнабели в GRUB. + +> ⚠️ Альтернативный обход для диагностики без паники: импорт **readonly** (`zpool import -o readonly=on RED_2TB`) может не паниковать, но данные могут быть недоступны из-за permission errors. + +**Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. + -> ⚠️ Урок: перетыкание дисков НЕ всегда триггерит авто-импорт, даже когда все члены на месте и ZFS работает по GUID. Буквы могут смениться (`sdc`→`sdb`), и пул ждёт ручного Import. Не паниковать — данные целы, пока все члены `ONLINE` в `lsblk`/by-id. - Идёт регулярный scrub (запускается ночью воскресенья). - **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`).