---
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 рабочий **только когда случился инцидент**. Это нехорошо.