git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1d621faa59bcf48395ccac4b95dac82e3dafe7b3
obsidian-vault/family/how-to/truenas-sata-ports-and-zfs-pools.md
T

30 KiB
Raw Blame History

TrueNAS — SATA порты и пулы

Обновлено: 2026-08-18 (datasets смонтированы под root, rsync перезапущен). СТАТУС: данные RED_2TB на этапе выгрузки на IronWolf — смонтированные дочерние datasets готовы к rsync. IronWolf 12TB = целевой пул DEST (rw, 10.6T свободно). HGST сломан (см. ниже).

⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, datasets смонтированы, данные выгружаются rsync

Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — паники больше нет. ПРОГРЕСС 2026-08-18: дочерние datasets (storage, backup, Photos, Edu, docker, old-bu, TimeMachine/guest, iocage/*) успешно смонтированы под root (zfs mount -a + при необходимости mount -o remount,rw /). Данные видны. Выгрузка на IronWolf идёт rsync (см. блок ниже).

ТЕКУЩИЙ БЛОКЕР (конец сессии):

  • zpool import/mount требуют root (some devices require root privileges). truenas_admin НЕ root (sudo просит пароль). Все операции с пулом — только под root.
  • Нужно добыть root: SSH → включить root login (PermitRootLogin), или выполнять команды через WebUI-админ/консоль.
  • IronWolf 12TB подключён к материнке (sdc) как целевой диск для спасения данных. На нём создан пул-приёмник DEST (rw, ONLINE, ~10.6T свободно), монтируется на /mnt/IRONWOLF. Первая попытка rsync скопировала только 355G (см. блок 2026-08-18 ниже).
  • WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны.

⚠️⚠️ ПРОБЛЕМА №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-диске.

Состояние (на 2026-08-17): подтверждён аппаратный отказ — диск не ремонтопригоден. Симптом: ритмичный «click-click, click-click» при работающем моторе = головки не могут выйти на дорожку/парковку (классический click of death после удара). Это механическое повреждение, НЕ лечится программно (SMART/прошивка), чинить может только профи-recovery и это дороже нового диска. Данных на нём НЕТ (не был добавлен в пул, только новая разметка sdf1/sdf2) — поэтому списан без recovery. Закрыто.

⚠️ Урок для будущего: enterprise-диск, уроненный на пол работающим — почти всегда аппаратная смерть (мотор/головки). Если на диске критичные данные — только профи-recovery, и шанс не 100%.

🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон на пол — аппаратный отказ (click of death).

✅ РЕШЕНО (исторически): 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, после подключения IronWolf для спасения):

  • Буквы разъехались ещё раз. Финальный lsscsi: sda=WD4TB, sdb=Kingston boot, sdc=⭐ IronWolf 12TB (целевой для спасения), sdd=Seagate4TB. WD 2TB#1 (WD-WXH2A31D5HDJ) СЕЙЧАС ОТКЛЮЧЁН / НЕ в системе (отсоединяли, чтобы загрузиться без паники).
  • ⭐ IronWolf 12TB подключён к материнке и ЛИНКУЕТСЯ — sdc = ST12000NT001-3LX101, 10.9T, by-id WV700FQ5. Он свободен (не в пуле) и определён как целевой диск для спасения данных с RED_2TB. На нём ещё НЕ создан пул-приёмник.
  • Карта ASMedia ASM1166 вытащена — lspci показывает только Intel H77 (00:1f.2). WD 2TB#2 перенесён с карты, затем был намеренно отключён пользователем.
  • HGST 12TB (HUH721212ALE600) — УРОНЕН НА ПОЛ, аппаратный отказ (см. блок КРИТИЧНО), считается вышедшим из строя.

⚠️ Буквы (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).

Пул Размер Члены (по /sbin/zpool status от 2026-08-17) Топология Монтирование
RED_2TB 5.44T (4.60T занято) state ONLINE, 0 0 0 ошибок, "No known data errors": sdd2 (WD2TB#1) + mirror-1 {sdc2 WD4TB, sdb2 Seagate4TB} — буквы по последнему status, сверять by-id (буквы shift-аются) 1 диsk (WD2TB#1) + mirror-1 (WD4TB+Seagate) /mnt — readonly-импорт, datasets не смонтированы, данные НЕ выгружены
boot-pool 111G (7.65G занято) sdb3 (Kingston 120GB boot SSD) 1 диск —
  • RED_2TB: HEALTH ONLINE по zpool status (readonly-импорт не паникует), scrub «завис» на ~72% (при readonly не доходит — но это НЕ фикс, см. ниже). Все ошибки 0 0 0 — данные целы. Один vdev (WD2TB#1) simplex — без зеркала; WD2TB#1 сейчас физически отключён.

✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена

Рабочий рецепт получения доступа к данным подтверждён на практике. Члены пула физически на месте: sda2=WD2TB#1 (ata1), sdb2=WD4TB (ata2, буква сменилась), sde2=Seagate4TB (ata6).

Что сработало (пошагово):

  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»): 
    zpool import -o readonly=on RED_2TB
    → 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 (после обхода паники). Точки монтирования не создаются.

СЛЕДУЮЩИЙ ШАГ (не завершён): смонтировать datasets вручную в существующую/записываемую точку (корневая / readonly). Порядок:

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

Критичные ограничения (выяснены по ходу):

  • zpool import требует root (some devices require root privileges) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root. На конец сессии это главный блокер — без root не смонтировать/выгрузить.
  • Раньше при readonly-импорте в тредах было: datasets показываются но пути «not found», и полностью нечитаемы (permission denied) если данные повреждены. Здесь readonly-импорт прошёл чисто (no panic) — но монтирование ещё не доведено до конца.
  • Данные на пуле важно выгрузить на другие диски (пул восстановится только пересозданием — аппаратная метаданная ошибка). Это главный незавершённый шаг.

🧪 ИТОГ ПО «ПОЧИНИТЬ ПУЛ» (2026-08-17, важно для будущих сессий):

  • In-place «починки» НЕТ. По mav (лидер OS-команды iXsystems) в тредах: "I don't know a way to recover from this situation without data offload and pool recreation". Паника на space map не лечится флагами.
  • Опции это НЕ решают: zfs.zfs_recover=1, zfs.zil_replay_disable=1 (в GRUB), rd.break=pre-mount, rd.break — все НЕ помогли (паника осталась). Readonly-импорт («doesn't even read space maps») — единственное, что не паникует и даёт доступ к данным.
  • -F (восстановление) уже показал панику в этой сессии (adding existent segment to range tree). Повторный -F на повреждённом пуле рискован — может углубить повреждение. Не жать вслепую.
  • zpool attach RED_2TB <wd2tb2> (идея зеркала на 2 WD2TB) НЕ выполнима в текущем состоянии: attach — это write, он пишет в space maps (обновляет метаданные) → паника. Readonly-импорт не даст attach; переимпорт в rw вернёт панику. Также 2TB не влезет под 4.6T данных целиком. Идея зеркала валидна только ПОСЛЕ пересоздания пула из спасённых данных.
  • Правильная дорога (единственная надёжная): readonly-импорт → смонтировать datasets вручную → выгрузить данные на целевой пул (IronWolf 12TB) → пересоздать RED_2TB → вернуть данные. Попытки «починить rw» возможны, но только ПОСЛЕ спасения данных и на свой риск.
  • Для «100% восстановления с правами»: rsync -aHAX (права, владельцы, ACL, xattr, хардлинки) или zfs send | zfs recv (идеально байт-в-байт со снимками, но требует пула-приёмника и снимка).

⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок.

🆕 ПРОГРЕСС (2026-08-18): datasets смонтированы под root, выгрузка идёт rsync — НЕ send|recv

Смонтирование дочерних datasets — РАБОТАЕТ под root. Это снимает блокер «datasets не смонтированы» из прошлой сессии:

mount -o remount,rw /        # если корневая ФС readonly мешает создавать mountpoint-ы
zfs mount -a                 # смонтировать все datasets
# проверить:
df -h /RED_2TB               # должно показать ~4.6T, а НЕ 1.1T/362G родительского
ls /RED_2TB/storage | head   # должно быть не пусто (Cartoons, Downloads, Movies...)

После zfs mount -a в mount видны все дочерние datasets на /RED_2TB/* (все ro — readonly, для чтения rsync это норм).

⚠️ СМОНТИРОВАТЬ datasets под truenas_admin НЕЛЬЗЯ — zfs mount -a даёт Insufficient privileges. Монтирование и выгрузка — только под root.

🐛 Причина «только 355G» на первой выгрузке rsync (разгадана): первая попытка rsync /RED_2TB/ /mnt/IRONWOLF/ запускалась, когда дочерние datasets НЕ были смонтированы, поэтому /RED_2TB/storage (3.24T), /RED_2TB/backup (287G) и т.д. были пустыми mountpoint-дирами. rsync скопировал только ~355G, лежащих прямо в родительском dataset RED_2TB (REFER 362G: .DS_Store, dedupe_rm.sh, files.txt.xz, docker.bak, system, immich-photos-upload). rsync не сломался — ему просто нечего было копировать из не смонтированных дочерних datasets. После монтирования данных стало ~4.6T — rsync перезапущен.

❌ zfs send | zfs recv НЕ работает на повреждённом пуле — использовать rsync: при zfs send RED_2TB/storage | zfs recv DEST/storage (под root) recv падает с signal received / Bad file descriptor / IOT instruction (core dumped), exit 1. ZFS не может прочитать данные/метаданные из пула с повреждённой space map на лету при stream-чтении. rsync — правильный и единственный надёжный способ (переживает ошибки чтения отдельных файлов, exit 23, копирует остальное).

⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send: под truenas_admin zfs send -n RED_2TB/docker возвращал exit 0 без ошибок — это ОБМАНЧИВО. Реальный zfs send (без -n) даёт warning: cannot send 'RED_2TB/docker': permission denied. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send.

Команды выгрузки (под root):

rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 &
# прогресс:
while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2.log; pgrep -a rsync >/dev/null && echo RUNNING || echo DONE; sleep 15; done

Итог выгрузки: после монтирования datasets и перезапуска rsync должны лечь все ~4.6T (storage, backup, Edu, Photos, TimeMachine/guest, old-bu, docker...). После завершения — сверка du -sh /mnt/IRONWOLF/ vs zfs list RED_2TB и обновить таблицу членов пула.

Опция добавить 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 нет.

Reference in New Issue View Git Blame Copy Permalink