git_admin/obsidian-vault

Fork 0

Files

T

Alexey Martemyanov d01c84c2bc [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md

2026-08-17 14:49:16 +06:00

22 KiB

Raw Blame History

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) уронили на пол, будучи подключённым. Развитие сценария (как происходило):

После удара — сектор 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, ошибку вернул сам диск.
smartctl мог прочитать INFO-секцию (Model: HGST HUH721212ALE600, 8CKD08RE, FW LEBDT3P2, 512e, SATA 6.0 Gb/s, SMART enabled) — контроллер жив, линк поднят.
На 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/модели.

Когда диск заведётся и добавится в пул — обновить таблицу портов выше и удалить этот блок «Следующие шаги».

Диагностические команды (полезно для будущих проверок)

# какие диски видит система и где
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):

В загрузочном меню GRUB (при старте держать Shift/ESC) выбрать ядро TrueNAS, нажать e, в строке с linux/vmlinuz добавить в конец:
```
zfs.zfs_recover=1 zfs.zil_replay_disable=1
```
Ctrl+X загрузиться. Это даёт системе дойти до консоли/WebUI без паники (Panic→warning).
Под root импортировать пул аккуратно (не форс-катастрофически с наскоку):
```
/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.
После импорта: /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 нет.

22 KiB Raw Blame History Unescape Escape