[2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md
This commit is contained in:
@@ -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 <wd2tb2>`): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.
|
||||
|
||||
|
||||
> ⚠️ Урок: перетыкание дисков НЕ всегда триггерит авто-импорт, даже когда все члены на месте и ZFS работает по GUID. Буквы могут смениться (`sdc`→`sdb`), и пул ждёт ручного Import. Не паниковать — данные целы, пока все члены `ONLINE` в `lsblk`/by-id.
|
||||
|
||||
- Идёт регулярный scrub (запускается ночью воскресенья).
|
||||
- **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`).
|
||||
|
||||
Reference in New Issue
Block a user