import: merge .wiki/concepts/ from temp prefix into existing dir (history preserved via merge+rename)

.wiki/concepts/wd40efax-smr-cascade.md

@@ -0,0 +1,76 @@
+---
+title: WD40EFAX SMR Cascade — root cause NAS failure 2026-05-18
+type: concept
+tags: [hardware, raid, smr, failure-mode, wd, lessons]
+sources: [../sources/nas-recovery-session-2026-05-18.md]
+updated: 2026-05-19
+---
+
+# WD40EFAX SMR Cascade
+
+Сценарий смерти RAID 5 на WD Red WD40EFAX (SMR-диски). Случился 2026-05-18 на [[dead-synology-diskstation]]. Известная community-проблема, не уникальная.
+
+## Что такое SMR
+
+**SMR** (Shingled Magnetic Recording) — способ записи на пластины, где дорожки наезжают друг на друга как черепица. Плюс: больше плотность, дешевле гигабайт. Минус: запись на одну дорожку **физически портит соседние** → нужна re-write whole "zone". Запись стала зональной (вместо random-access).
+
+**CMR** (Conventional Magnetic Recording) — стандарт, дорожки независимые.
+
+### Где SMR ломается
+
+| Сценарий | CMR | SMR |
+|---|---|---|
+| Sequential write | ✅ | ✅ |
+| Чтение | ✅ | ✅ |
+| Random writes (БД, активная FS) | ✅ | ❌ просаживается |
+| **RAID rebuild** | ✅ | ❌❌ **смертельно** |
+
+Во время RAID-rebuild диск получает **долгую sustained-нагрузку**: parity-чтение + запись на новый диск. SMR-firmware пытается жонглировать зонами; внутренний CMR-кэш (есть в начале диска) забивается. Performance падает в 5-10 раз → **command timeouts** → RAID-контроллер выкидывает диск из массива.
+
+## Скандал WD
+
+WD в 2018-2020 **тихо** перевёл часть линейки "WD Red" (заточена под NAS) на SMR, не указав в маркировке. Community catch'нуло (Reddit, Servethehome, forum.synology). Class-action в США 2020, WD settled. После — WD переименовал CMR-варианты в "WD Red **Plus**" / "WD Red **Pro**"; "WD Red" без Plus остался SMR.
+
+**WD40EFAX-68JH4N1, WD40EFAX-68JN4N0** — главные жертвы. Если в RAID — лотерея.
+
+## Конкретный путь к смерти (наш кейс)
+
+1. **3-диск RAID 5** на WD40EFAX. Storage pool в DSM на `cachedev_0`, 7 TB usable.
+2. **Начало мая 2026** — один из 3 дисков вылетел (вероятно тайм-аут под нагрузкой, не физический отказ).
+3. **Пул degraded.** RAID 5 на 3 дисках теперь толерирует 0 дополнительных отказов.
+4. **2 недели пользователь не заменил failed диск.** Пул работал в degraded; оставшиеся 2 SMR-диска делают parity-чтение для любого запроса.
+5. **Под этой нагрузкой второй WD40EFAX накопил тайм-ауты** (известный паттерн для SMR в degraded-RAID).
+6. **2026-05-18 ~17:00 MSK** — второй вылет. Пул past redundancy, "Сбой сборки" в DSM Storage Manager.
+7. **Виден только Disk 3 + Disk 8** (третий, который вылетел первым, физически не определяется системой даже).
+
+## Ключевая ошибка
+
+**2 недели в degraded не лечатся.** В нормальном RAID 5 на CMR — можно прожить недели без последствий (всё работает). На SMR — каждый день в degraded **повышает шанс второго отказа** из-за SMR-induced таймаутов.
+
+Правило: при SMR в RAID 5 — **24-48 часов** на замену failed диска. Дольше — лотерея. Поэтому SMR в RAID **запрещён de facto** для серьёзных продакшнов.
+
+## Что НЕ делать после второго отказа
+
+- ❌ Repair / Online Assembly в DSM — пул past redundancy, mdadm не соберёт.
+- ❌ Менять disks в degraded-пуле — может ускорить deterioration оставшихся.
+- ❌ Запускать `mdadm --assemble` руками с force — без знания внутренней структуры → разрушение partial-data.
+
+## Что МОЖНО (но дорого)
+
+- **Pro data recovery** (Storelab/R.LAB/Ace Lab клиенты): $500-3000 typical. Контора берёт диски (все 3, включая failed), делает offline-reconstruct parity, восстанавливает file-tree. Подходит для возврата 9-дневного окна между последним бэкапом (2026-05-09) и инцидентом (2026-05-18).
+- **Условие:** диски физически живы (головки не упали). У нас 2 видимых "Исправно" + 1 не определяемый — стандартный кейс для recovery service.
+
+## Lessons для будущего
+
+Для следующего NAS-пула:
+
+1. **CMR-only.** Никаких WD40EFAX/EFRX/EFAZ/EFGX (если они SMR). Кандидаты:
+   - WD Red **Plus** (CMR, маркировка "Plus" — важно)
+   - WD Red **Pro** (CMR, enterprise-grade)
+   - Seagate IronWolf 4TB+ (CMR — модели <4TB могут быть SMR, проверять по datasheet)
+   - HGST/WD Ultrastar (enterprise CMR)
+2. **RAID 6 / SHR-2** при 4+ дисках — толерирует 2 отказа. Один отказ + один SMR-cascade не убивает массив.
+3. **Дисциплина replace failed disk в 24-48 часов** — в degraded долго не сидеть.
+4. **Hot spare** если есть place в шасси.
+5. **Hyper Backup ежедневно** (а не "по триггеру") + retention 30+ дней.
+6. **Тест восстановления раз в квартал** — мы впервые узнали что наш backup рабочий **только когда случился инцидент**. Это нехорошо.