198 lines
22 KiB
Markdown
198 lines
22 KiB
Markdown
# TrueNAS — SATA порты и пулы
|
||
|
||
> Обновлено: 2026-08-17 ночь (два КРИТИЧНО: HGST упал и сломан; RED_2TB вызывает kernel panic — см. раздел пулов)
|
||
|
||
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №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) **уронили на пол, будучи подключённым**. Развитие сценария (как происходило):
|
||
|
||
1. **После удара — сектор 0 стал нечитаем** (по USB-мосту): ядро давало `critical medium error, dev sdf, sector 0` → `Add. Sense: Unrecovered read error` → `unable to read partition table` / `unable to read RDB block 0`. Разметка (`sdf1`/`sdf2`) пропала. Это НЕ ошибка моста/кабеля — `hostbyte=DID_OK driverbyte=DRIVER_OK`, ошибку вернул сам диск.
|
||
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-тест не удалось прогнать, т.к. диск щёлкает.
|
||
|
||
**Что НЕ делать:** не махать диском, не запускать запись/ремонт сектора 0 до понимания масштаба, не использовать как свежий пул — доверие к диску утрачено. Если диск ещё вращается — прогонять длинный SMART-тест по SATA (с Molex-питанием) чтобы оценить `Current_Pending_Sector`.
|
||
|
||
> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон — теперь состояние под вопросом.
|
||
|
||
---
|
||
|
||
## ✅ РЕШЕНО (исторически): HGST 12TB заводился — проблема была в 3.3V PWDIS, НЕ в карте
|
||
|
||
**2026-08-17.** HGST **линуется и полностью работает** теперь. Ключевое изменение — **отключена/обезврежена 3.3V линия (PWDIS-контакт №3 на SATA-разъёме питания)**. Диск:
|
||
- определяется как `/dev/sde`, `HGST HUH721212ALE600`, серийник `8CKD08RE`, **10.9T**, секторов `23437770752` (штатная ёмкость 12TB по SFF-8447)
|
||
- **подключён на карте ASMedia (ata7 = 0000:02:00.0, host7)** — той самой, где раньше НЕ линковался!
|
||
- **разметка сохранена без переразметки**: `sde1`=200M, `sde2`=10.9TB (та GPT, что была и через USB)
|
||
|
||
**Вывод:** причина молчания была **100% в 3.3V Power Disable (PWDIS)** — enterprise-диск с поддержкой PWDIS не раскручивается, когда обычный БП подаёт 3.3V на пин №3 SATA-питания. Снятие 3.3V-контакта устранило проблему. **Карта ASM1166 и порт материнки при этом работали и раньше.** Переразметка для решения НЕ требуется.
|
||
|
||
## Материнская плата
|
||
|
||
**ASUS P8H77-V LE**, чипсет Intel H77.
|
||
6 SATA портов на Intel контроллере (порт от ASMedia отсутствует).
|
||
|
||
### Распределение портов (актуально на конец 2026-08-17, после финального перетыкания)
|
||
|
||
| Порт (ata) | Тип | Скорость | Цвет | Диск | by-id |
|
||
|------------|-----|----------|------|------|-------|
|
||
| ata1 (SATA6G_1) | SATA 3 | 6 Gb/s | серый | **sda** — WD 2TB (WD20EFAX) | WD-WXH2A31D5HDJ |
|
||
| ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | **sdb** — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 |
|
||
| ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | **sdc** — ⭐ **IronWolf 12TB (ST12000NT001)** | WV700FQ5 |
|
||
| ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | **sdd** — Kingston 120GB SSD (boot) | 50026B77844E881C |
|
||
| ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *(свободен/не иден-тиф.)* | — |
|
||
| ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sde** — Seagate 4TB (ST4000DM004) | WFN66CM2 |
|
||
| *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (вытащена) | — |
|
||
|
||
**⚠️ Фактическое положение на конец сессии (2026-08-17):**
|
||
- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`) и не относящийся к делу PCIe-to-PCI bridge ASM1083. WD 2TB#2 перенесён с карты на материнку.
|
||
- **⭐ IronWolf 12TB теперь ПОДКЛЮЧЁН и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он не в пуле (новый диск).
|
||
- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) НАМЕРЕННО отключён** пользователем (2026-08-17). Раньше был `sdb` (перенесён с карты), затем Alex его отключил «это норм». Сейчас отсутствует по замыслу, а не по ошибке.
|
||
- **HGST 12TB (`HUH721212ALE600`)** — был подключён по USB (виден как `sdf`, model HGST, WWN `0x5000cca26fefbc05`) и после удара о пол НЕ работает надёжно (см. блок КРИТИЧНО в самом верху). На текущий момент считаем его вышедшим из строя.
|
||
|
||
> ⚠️ Буквы (`sda`/`sdb`) **shift-аются при перетыкании** и сейчас разъехались: `sdb` = WD4TB (не WD2TB#2!), `sdc` = IronWolf. **Всегда сверять по by-id/модели, не полагаться на буквы.**
|
||
|
||
> ⚠️ ⚡ **СРОЧНО:** пул `RED_2TB` после этого перетыкания НЕ заимпортирован (см. блок «КРИТИЧНО» в разделе пулов). Все члены на месте — нужен Import Pool.
|
||
|
||
## Плата расширения SATA в PCIe (установлена ~2026-07-30)
|
||
|
||
**PCIe карта:** ASMedia ASM1166 (PCI ID `1b21:1166`, rev 02), на шине `02:00.0` (под PCIe bridge `0000:00:1c.0`).
|
||
Контроллер виден ядру (драйвер `ahci` активен), подсистема: ZyDAS Technology Corp.
|
||
|
||
**Состояние (диагностика 2026-07-31):**
|
||
- Контроллер создал **32 ата-порта** (`ata7`–`ata38` на 0000:02:00.0). ⚠️ Это НЕ типичные 6 портов чистой ASM1166 — вероятно плата с расширенным числом портов / мультиплексированием. Уточнить физическое число разъёмов.
|
||
- **На НИ ОДНОМ порту карты нет ни одного подключённого/живого диска**: у всех 32 портов в sysfs только `ata_port host link power uevent`, отсутствуют `target*` и блок-устройства.
|
||
- `lsscsi` показывает диски только на Intel-хостах 0,1,2,3,5. Хосты карты (7–38) без дисков.
|
||
- В `/dev/disk/by-id` только 5 дисков — все на материнке.
|
||
|
||
**Целевой диск:** HGST 12TB (Ultrastar) — для него и покупалась PCIe SATA-карта. В плане значился как «по USB определяется как sde, USB-карман не нужен, вставить по SATA».
|
||
|
||
**✅ Заключение после решающего теста (карта исправна, дело в HGST):**
|
||
- **Карта 100% исправна.** При подключении заведомо рабочего WD 2TB (второго WD20EFAX, `WD-WXJ2A31CUNNT`) в порт карты она **определилась** — появился `host9`→`target9:0:0` с блок-устройством `/dev/sde`. Значит слот/порты/кабель AHCI работают, питания хватает.
|
||
- У карты **нет отдельного разъёма питания** (питается от PCIe-слота). Диск питается от БП напрямую.
|
||
- Проверены физические порты карты **1 и 6** — оба без линка для HGST.
|
||
|
||
**✅ Дополнительный тест HGST через USB (2026-08-01) — диск полностью исправен:**
|
||
- HGST 12TB подключён через **USB-мост JMicron** (`152d:0578`, "USB to ATA/ATAPI Bridge") на xHCI-порт (`usb3/3-1`).
|
||
- Ядро определило его как **/dev/sdf**, модель **HGST HUH721212ALE600**, **полная ёмкость 10.9 TB** (23 437 770 752 сектора × 512 B — точно размер 12TB-драйва).
|
||
- Диск размечен: `sdf1` = 200M, `sdf2` = 10.9TB.
|
||
- Через USB диск заводится, читается на всю ёмкость и виден целиком.
|
||
|
||
**➡️ Уточнённый диагноз:** проблема **именно в паре HGST SATA-интерфейс ↔ SATA-карта ASMedia**, а не в самом диске. Диск работоспособен. Две вероятные причины не-линка по SATA в карте: (1) питание с SATA-разъёма БП до диска в карте не доходит (в USB-боксе питание даёт мост/свой блок, потому и работает), либо (2) enterprise-диск (4Kn/особый PHY) не поднимает линк на ASM1166. USB-мост — рабочий способ диагностики, но ненадёжен как постоянное решение для ZFS.
|
||
|
||
## ✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает
|
||
|
||
> ⚠️ **Актуальный статус на 2026-08-17 ночь:** HGST **УРОНЕН НА ПОЛ и сломан** (см. блок КРИТИЧНО в самом верху). Карта ASM1166 вытащена из слота, IronWolf подключён на материнку. Этот блок фиксирует **как изначально решалась причина не-линка** (PWDIS) — полезно для понимания, но теперь диск вышел из строя механически.
|
||
|
||
Проблема не-линка HGST по SATA **решена: это 3.3V PWDIS на SATA-питании.** Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Когда диск снова будет подключён — добавить в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок.
|
||
|
||
**Что было/что стало:**
|
||
- Было: HGST не давал `target*` ни на одном порту карты ASM1166 (USB-мост работал, потому что питание подавал мост, не затрагивая PWDIS).
|
||
- Стало: после отключения 3.3V-контакта HGST линкуется на той же карте (ata7/02:00.0) — карта и материнка исправны, дело было в питании.
|
||
- **Переразметка для решения не нужна** — проблема на уровне PHY/питания, а не данных.
|
||
|
||
> ⚠️ Если такой же enterprise-диск (HGST/WD Ultrastar/Seagate Exos c PWDIS) снова «молчит» по SATA — первым делом проверить 3.3V-пин №3 питания: Molex→SATA адаптер (без 3.3V) или изоляция пина №3 решают.
|
||
|
||
> ⚠️ NB: буквы дисков (`sda`/`sdb`/...) **shift-аются при перетыкивании** — сейчас на материнке: [0]=WD2TB, [2]=WD4TB, [3]=Kingston boot, [5]=Seagate4TB, IronWolf на [1]. Не полагаться на буквы, проверять по `by-id`/модели.
|
||
|
||
> Когда диск заведётся и добавится в пул — **обновить таблицу портов выше** и удалить этот блок «Следующие шаги».
|
||
|
||
## Диагностические команды (полезно для будущих проверок)
|
||
```bash
|
||
# какие диски видит система и где
|
||
lsscsi -H; lsscsi -g
|
||
# какие порты создала карта и живы ли (target = есть диск)
|
||
ls /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/ata*
|
||
# для каждого порта карты — есть ли подключённое устройство (target*):
|
||
for a in /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/ata*/host*; do
|
||
tgt=$(ls -d "$a"/target* 2>/dev/null); [ -n "$tgt" ] && echo "$a: $tgt"
|
||
done
|
||
# контроллеры
|
||
lspci -k | grep -i sata
|
||
```
|
||
|
||
## Подключение дисков (исходный план)
|
||
|
||
- **HGST 12TB (sde, USB)** — при подключении по SATA: в серый порт **SATA6G_2 (ata2)**. Диск enterprise, 6Gb/s. Ему не нужен USB-карман.
|
||
- **Seagate IronWolf** — в синий порт **SATA3G_3 (ata5)**. HDD не упирается в 3Gb/s (~300MB/s пропускная), смысла в 6Gb/s нет.
|
||
- **Kingston SSD (boot)** — оставить в синем порту SATA3G_2 (ata4). Вся активность только при загрузке, система работает из RAM.
|
||
- **WD 2TB** — серый SATA6G_1 (ata1), занят.
|
||
|
||
## Важно про ZFS и перетыкание
|
||
|
||
- ZFS не привязана к букве диска или SATA порту. TrueNAS распознаёт пул по GUID на дисках.
|
||
- **Перетыкание НЕ всегда поднимает пул автоматически** (2026-08-17: RED_2TB не заимпортировался сам после перетыкания, см. «КРИТИЧНО» ниже). Если пул не виден в `zpool list` — нужен ручной Import (WebUI Storage → Import Pool или `zpool import <pool>` под root). Данные при этом целы, пока все члены `ONLINE`.
|
||
- Проверка пула после перетыкания: `/sbin/zpool status <pool>` — убедиться что все члены `ONLINE`, ошибки `0 0 0`.
|
||
|
||
## Пулы TrueNAS (проверено 2026-08-17)
|
||
|
||
Имена пулов, топология и члены — проверять статус через `/sbin/zpool` (см. ниже про PATH).
|
||
|
||
| Пул | Размер | Члены (по /dev со стабильным подключением) | Топология | Монтирование |
|
||
|-----|--------|-----------|-----------|--------------|
|
||
| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdb2`/`sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` — **⚠️ ПОТРЕБУЕТСЯ IMPORT, см. ниже** |
|
||
| **boot-pool** | 111G (7.65G занято) | `sdd3` (Kingston 120GB boot SSD) | 1 диск | — |
|
||
|
||
- RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала.
|
||
|
||
### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB не импортируется — вызывает KERNEL PANIC
|
||
|
||
После перетыкания дисков на материнке пул **RED_2TB не поднялся автоматически**, и при попытке `zpool import -F` система упала в **kernel panic bootloop**:
|
||
|
||
```
|
||
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 импортировать пул аккуратно** (не форс-катастрофически с наскоку):
|
||
```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>`): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.
|
||
|
||
|
||
|
||
- Идёт регулярный scrub (запускается ночью воскресенья).
|
||
- **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`).
|
||
|
||
## Запрещено
|
||
|
||
- **Boot pool (Kingston 120GB SSD)** — нельзя использовать для Docker, файлов, app data. TrueNAS обновления могут пересоздать boot pool. Размер 120GB мал для логов/образов.
|
||
|
||
## SATA кабель
|
||
|
||
Любой стандартный SATA кабель подходит. Разницы между кабелями для SATA 2 и SATA 3 нет.
|