[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:
@@ -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