[2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md
This commit is contained in:
Alexey Martemyanov
@@ -1,10 +1,10 @@
|
||||
# TrueNAS — SATA порты и пулы
|
||||
|
||||
> Обновлено: 2026-08-17 ночь (два КРИТИЧНО: HGST упал и сломан; RED_2TB вызывает kernel panic — см. раздел пулов)
|
||||
> Обновлено: 2026-08-17 глубокая ночь (РО: HGST упал и сломан; RED_2TB импортирован READONLY — смонтировать datasets и выгрузить — см. раздел пулов)
|
||||
|
||||
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB вызывает KERNEL PANIC (важнее HGST)
|
||||
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы (данные ещё НЕ выгружены)
|
||||
|
||||
См. раздел «Пулы TrueNAS» → блок «RED_2TB не импортируется — вызывает KERNEL PANIC». Это приоритет №1 — данные реально есть. Система в panic loop; рецепт: тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем import.
|
||||
См. раздел «Пулы TrueNAS» → блок «RED_2TB readonly-импорт». **Прогресс:** пан-loop преодолён (см. рецепт ниже), RD_2TB импортирован readonly успешно. **Осталось смонтировать datasets вручную и выгрузить данные** — точка монтирования не создалась из-за read-only корневой ФС. Это приоритет №1 — данные есть.
|
||||
|
||||
## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения
|
||||
|
||||
@@ -14,11 +14,11 @@
|
||||
2. **smartctl мог прочитать INFO-секцию** (`Model: HGST HUH721212ALE600`, `8CKD08RE`, FW `LEBDT3P2`, 512e, SATA 6.0 Gb/s, SMART enabled) — контроллер жив, линк поднят.
|
||||
3. **На MacBook через USB-мост диск «щёлкает» и не шуршит головкой при старте** — признак механических проблем после удара (головки/мотор). КЛИК-ОФ-ДЕФ возможен, но также нельзя исключать нехватку питания через USB-мост на 12TB-диске.
|
||||
|
||||
**Состояние:** не подтверждён полный отказ, но высокая вероятность аппаратного повреждения от падения. Сектор 0 (начало диска /GPT) повреждён точно. Масштаб (1 сектор или сотни) НЕ определён — длинный SMART-тест не удалось прогнать, т.к. диск щёлкает.
|
||||
**Состояние (на 2026-08-17):** **подтверждён аппаратный отказ — диск не ремонтопригоден.** Симптом: ритмичный «click-click, click-click» при работающем моторе = головки не могут выйти на дорожку/парковку (классический click of death после удара). Это механическое повреждение, НЕ лечится программно (SMART/прошивка), чинить может только профи-recovery и это дороже нового диска. **Данных на нём НЕТ** (не был добавлен в пул, только новая разметка sdf1/sdf2) — поэтому списан без recovery. Закрыто.
|
||||
|
||||
**Что НЕ делать:** не махать диском, не запускать запись/ремонт сектора 0 до понимания масштаба, не использовать как свежий пул — доверие к диску утрачено. Если диск ещё вращается — прогонять длинный SMART-тест по SATA (с Molex-питанием) чтобы оценить `Current_Pending_Sector`.
|
||||
> ⚠️ Урок для будущего: enterprise-диск, уроненный на пол работающим — почти всегда аппаратная смерть (мотор/головки). Если на диске критичные данные — только профи-recovery, и шанс не 100%.
|
||||
|
||||
> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон — теперь состояние под вопросом.
|
||||
> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон на пол — аппаратный отказ (click of death).
|
||||
|
||||
---
|
||||
|
||||
@@ -139,47 +139,43 @@ lspci -k | grep -i sata
|
||||
|
||||
- RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала.
|
||||
|
||||
### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB не импортируется — вызывает KERNEL PANIC
|
||||
### ✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена
|
||||
|
||||
После перетыкания дисков на материнке пул **RED_2TB не поднялся автоматически**, и при попытке `zpool import -F` система упала в **kernel panic bootloop**:
|
||||
**Рабочий рецепт получения доступа к данным подтверждён на практике.** Члены пула физически на месте: `sda2`=WD2TB#1 (ata1), `sdb2`=WD4TB (ata2, буква сменилась), `sde2`=Seagate4TB (ata6).
|
||||
|
||||
```
|
||||
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)
|
||||
|
||||
**Сейчас система грузится В 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 импортировать пул аккуратно** (не форс-катастрофически с наскоку):
|
||||
**Что сработало (пошагово):**
|
||||
1. Тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB → **НЕ помогли** (всё равно паника). `rd.break=pre-mount` и `rd.break` → тоже НЕ помогли.
|
||||
2. **ЕДИНСТВЕННЫЙ рабочий способ загрузиться без паники:** физически ОТКЛЮЧИТЬ все диски проблемного пула (чтобы дойти до рабочего shell/WebUI), затем вставить обратно.
|
||||
- Включить с отключёнными дисками RED_2TB (WD2TB#, WD4TB, Seagate4TB) → boot-pool поднимается, паники нет.
|
||||
- Вставить диски обратно (горячо) в те же порты.
|
||||
3. **READONLY-импорт не паникует** (по mav из iXsystems: «read-only import doesn't even read space maps»):
|
||||
```bash
|
||||
/sbin/zpool import # какие пулы видит, без монтирования
|
||||
/sbin/zpool import -n RED_2TB # dry-run — нужен ли -F и не падает ли
|
||||
/sbin/zpool import -F RED_2TB # только если dry-run показал, что требуется -F
|
||||
zpool import -o readonly=on RED_2TB
|
||||
```
|
||||
> В треде TrueNAS подтверждено: `zpool import -f -F -X` «не срабатывало», а с тюнабелями в GRUB + импортом — срабатывает. Сначала тюнабели, потом import.
|
||||
→ **`Import was successful`** — паники нет, метаданные прочитаны! (попытка `zpool import -nRED_2TB` без `-F` невозможна; `-n` требует `-F` синтаксиса.)
|
||||
4. **⚠️ Текущий блок:** после readonly-импорта выдаются ошибки монтирования:
|
||||
```
|
||||
cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system
|
||||
Import was successful, but unable to mount some datasets
|
||||
```
|
||||
Причина: корневая ФС readonly (после обхода паники). **Точки монтирования не создаются.**
|
||||
|
||||
3. **После импорта:** `/sbin/zpool status RED_2TB` → оценить члена с ошибками. Снять важные данные с пула на другие диски при первой возможности (импорт `-F` + recover может ценой части изменений). Честно проверить RAM/ECC — в треде #31410 это был реальный фактор повреждения.
|
||||
**СЛЕДУЮЩИЙ ШАГ (не завершён):** смонтировать datasets вручную в существующую/записываемую точку (корневая / readonly). Порядок:
|
||||
```bash
|
||||
zfs list -r RED_2TB # какие datasets есть (zfs list работает без mount)
|
||||
# смонтировать в существующую пустую папку, не создавая новую (или через tmpfs/rw-точку)
|
||||
# например:
|
||||
# mkdir -p /mnt/rec 2>/dev/null; (если /mnt rw — иначе выбрать rw-точку)
|
||||
# zfs set mountpoint=/mnt/rec RED_2TB (или mount -o)
|
||||
# затем выгружать данные на запасные диски rsync
|
||||
```
|
||||
|
||||
> ⚠️ Пока пул не восстановлен, **НЕ запускать повторный автоимпорт/`-F` сипломи** — каждый заход углубляет риск. Сначала тюнабели в GRUB.
|
||||
**Критичные ограничения (выяснены по ходу):**
|
||||
- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root.
|
||||
- Раньше при readonly-импорте в тредах было: datasets показываются но пути «not found», и полностью нечитаемы (permission denied) если данные повреждены. Здесь readonly-импорт прошёл чисто (no panic) — но монтирование ещё не доведено до конца.
|
||||
- **Данные на пуле важно выгрузить на другие диски** (пул восстановится только пересозданием — аппаратная метаданная ошибка). Это главный незавершённый шаг.
|
||||
|
||||
> ⚠️ Альтернативный обход для диагностики без паники: импорт **readonly** (`zpool import -o readonly=on RED_2TB`) может не паниковать, но данные могут быть недоступны из-за permission errors.
|
||||
> ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок.
|
||||
|
||||
**Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB <wd2tb2>`): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.
|
||||
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
# TrueNAS — Восстановление ZFS пула при kernel panic (space map corruption)
|
||||
|
||||
> Создано 2026-08-17. Зеркало скила `truenas-zfs-panic-recovery`.
|
||||
|
||||
## Когда это нужно
|
||||
|
||||
Пул TrueNAS не импортируется и вызывает **kernel panic / boot loop**:
|
||||
```
|
||||
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)**. НЕ обязательно потеря данных, но структура пула повреждена. Read-write импорт паникует, т.к. читает битые space maps.
|
||||
|
||||
## Ключевая идея
|
||||
|
||||
**Read-only import НЕ читает space maps и НЕ паникует** (mav/iXsystems: "read-only imports don't even read space maps"). Стратегия: обойти панику → readonly-импорт → выгрузить данные → пересоздать пул.
|
||||
|
||||
**Пул НЕ «чинится»** — только выгрузка данных и пересоздание.
|
||||
|
||||
## Проверенные шаги (2026-08-17, TrueNAS SCALE 24.10)
|
||||
|
||||
### 1. Загрузка без паники — единственный рабочий способ:
|
||||
|
||||
**Физически отключить все диски проблемного пула** → boot-pool поднимается, паники нет → дошли до shell/WebUI → **воткнуть диски обратно (горячо)** в те же порты.
|
||||
|
||||
**Что НЕ работает (проверено):**
|
||||
- Тюнабели в GRUB `zfs.zfs_recover=1 zfs.zil_replay_disable=1` — не помогли
|
||||
- `rd.break=pre-mount` и `rd.break` — не помогли
|
||||
- `zfsforce=1` — не помогает
|
||||
|
||||
### 2. Readonly-импорт (под root):
|
||||
|
||||
```bash
|
||||
/usr/sbin/zpool import -o readonly=on RED_2TB
|
||||
```
|
||||
→ `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо.
|
||||
|
||||
### 3. Монтирование datasets вручную (root ФС readonly):
|
||||
|
||||
Ошибка `cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system` — из-за READONLY корневой ФС. Монтируй вручную в записываемую точку:
|
||||
```bash
|
||||
zfs list -r RED_2TB # список datasets (работает без mount)
|
||||
zfs set mountpoint=/mnt/rec RED_2TB # или mount -o
|
||||
```
|
||||
|
||||
### 4. Выгрузка:
|
||||
|
||||
```bash
|
||||
rsync -av --ignore-existing --ignore-errors /<pool>/ <резервный-диск>/
|
||||
```
|
||||
Лучше в tmux. Затем `zpool destroy` + пересоздать пул.
|
||||
|
||||
## Подводные камни
|
||||
|
||||
- `zpool` не в PATH для zsh-юзеров (`command not found`) — использовать `/sbin/zpool` или `/usr/sbin/zpool`.
|
||||
- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль.
|
||||
- `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`).
|
||||
- **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly.
|
||||
- `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum).
|
||||
- Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление).
|
||||
- **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest.
|
||||
- Буквы дисков shift-аются — сверять по by-id/модели, не по буквам.
|
||||
|
||||
## Root cause
|
||||
|
||||
`adding existent segment to range tree` = openzfs #15030 / #13483. Триггер: члены пула отвалились при перетыкании/перезагрузке, либо RAM corruption (non-ECC).
|
||||
Reference in New Issue
Block a user