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

77 lines
6.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
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 рабочий **только когда случился инцидент**. Это нехорошо.