SMR vs CMR: можно ли SMR в RAID

Два жёстких диска одинаковой ёмкости на бумаге могут вести себя в массиве совершенно по-разному. Один спокойно переживает длительную запись, rebuild и фоновую активность NAS, а второй внезапно проседает, тянет восстановление и иногда даже выглядит для контроллера как «подвисший». Именно поэтому вопрос о SMR в RAID нельзя свести к простому «да» или «нет».

SMR не является неудачной технологией сам по себе. Она появилась как способ повысить плотность записи и улучшить экономику хранения. Но для RAID важна не только цена за терабайт и не только скорость на пустом диске. Важнее то, как накопитель ведёт себя под длительной перезаписью, при нехватке idle-time, во время rebuild или resilver и под смешанной нагрузкой. Для домашнего NAS, офисного массива, backup-сервера, ZFS, mdadm и аппаратного RAID это уже не нюанс, а часть архитектуры. Принцип SMR как технологии повышения ёмкости за счёт перекрытия дорожек прямо описан SATA-IO, где отдельно отмечено, что производительность может зависеть от того, как этим управляет диск или хост.

Что такое CMR и SMR на практике

CMR (Conventional Magnetic Recording, иногда можно встретить PMR - Perpendicular Magnetic Recording) — это классическая схема записи, при которой дорожки размещаются без перекрытия. Когда диск получает команду на перезапись блока, он обычно может обновить данные локально и предсказуемо. Для RAID это важно не потому, что CMR «быстрее всегда», а потому, что его поведение под записью и фоновыми операциями обычно понятнее.

SMR (Shingled Magnetic Recording, «черепичная запись») работает иначе: дорожки частично перекрываются, что позволяет увеличить плотность записи и ёмкость. Цена этого выигрыша — более сложная перезапись. Изменение данных в одной области может потребовать внутренней реорганизации смежных участков, особенно когда речь идёт не о красивом последовательном потоке, а о длительной или случайной записи. Внешне диск может выглядеть как обычный SATA HDD, но внутри его firmware может выполнять дополнительные операции, которые пользователь напрямую не видит. Именно поэтому корректнее говорить не «SMR медленный, CMR быстрый», а «SMR и CMR отличаются предсказуемостью поведения под перезаписью и длительной записью». Это для RAID важнее, чем средняя скорость чтения.

Здесь важен ещё один слой различий. SMR бывает device-managed, host-aware и host-managed. В бытовых и SMB-сценариях чаще всего встречается device-managed SMR: хост видит обычный блоковый диск, а вся сложность скрыта внутри накопителя. Именно поэтому проблемы часто проявляются не в спецификации, а уже в нагрузке. Host-managed SMR — это совсем другой класс. Для него стек хранения должен осознанно работать с зонами и последовательной записью; zoned storage не считается plug-and-play заменой обычным дискам и требует специальной программной модели. Это прямо отражено и в Linux zoned storage documentation, и в материалах Western Digital.

Почему RAID делает разницу между SMR и CMR такой заметной

RAID ожидает от дисков не только доступной ёмкости. Ему нужна стабильная латентность, предсказуемая реакция на запись, отсутствие слишком длинных пауз и нормальное поведение во время rebuild, resilver, scrub и других фоновых операций. Когда диск внезапно уходит во внутреннюю переработку данных, массиву всё равно, почему именно это произошло: для контроллера или слоя хранения это выглядит как задержка ответа.

У SMR это особенно заметно в нескольких сценариях:

• при длительной непрерывной записи;
• после заполнения кэша и перехода к тяжёлой фоновой реорганизации;
• при rebuild или resilver, когда массив и так работает в напряжённом режиме;
• при частых мелких перезаписях;
• в массивах под VM, базы данных, файловые шары и активный NAS;
• при смешивании SMR и CMR в одном RAID.

Самый показательный тест на пригодность диска для RAID — восстановление массива. На больших HDD rebuild и без того занимает много времени, а в этот момент массив живёт с повышенным риском: отказ ещё одного диска или серьёзная деградация производительности становятся намного чувствительнее. Если накопитель в процессе восстановления дополнительно уходит в тяжёлую внутреннюю переработку данных, окно риска растягивается ещё сильнее. Это не означает, что SMR обязательно «сломает» массив, но означает, что его поведение под давлением менее предсказуемо. Microchip в white paper по SMR в RAID прямо пишет, что RAID-кэширование и buffering могут сгладить часть эффектов, но не отменяют природу самого накопителя и необходимость подбирать подходящие режимы работы.

Где SMR в RAID почти всегда плохая идея

Для активного NAS, где идут мелкие записи, индексация, snapshot’ы, синхронизация клиентов, резервные копии и фоновая housekeeping-активность, CMR почти всегда является правильным базовым выбором. Там важна не номинальная ёмкость, а предсказуемость under pressure.

То же относится к ZFS и RAIDZ под рабочей нагрузкой. Проблема не в том, что ZFS якобы «не любит SMR» как религия. Проблема в профиле операций: copy-on-write, resilver, scrub и sustained write-паттерны плохо сочетаются с consumer device-managed SMR. Western Digital в своей документации по WD Red прямо указывает, что WD Red Plus и WD Red Pro являются CMR и что именно их следует использовать с ZFS; при этом для DMSMR отдельно отмечается, что sustained random writes во время ZFS re-silvering лишают диск idle-time для внутренних задач управления данными.

Плохой идеей SMR обычно оказывается и для аппаратного RAID в production-сервере. Контроллер ждёт достаточно ровного поведения, а длинные firmware-паузы могут приводить к деградации массива, выпадению диска или, как минимум, к неприятным сюрпризам в окне обслуживания. Под хранилища для VM, почтовых систем, баз данных и активных файловых серверов выбор в пользу SMR тоже обычно экономит не там, где нужно: цена за терабайт ниже, но стоимость владения массивом может оказаться выше за счёт rebuild-time, потери предсказуемости и дополнительных операционных рисков.

Когда SMR всё-таки допустим

Сказать, что SMR в RAID «нельзя никогда», было бы так же неточно. Он допустим там, где профиль нагрузки ему подходит. Прежде всего это архивные и nearline-сценарии: крупная последовательная запись, потом в основном чтение, переписывание редко. В таких задачах выигрыш в ёмкости и цене за терабайт может быть рациональным.

Ещё один допустимый вариант — backup-репозиторий с предсказуемым окном записи. Если это пакетные процессы, а не постоянный random write, SMR может быть рабочим компромиссом. Но здесь важно смотреть не на сам ярлык «backup», а на конкретику: объём ежедневного прироста, длительность окна, retention, concurrency и вероятность частых перезаписей. Репозиторий, в который ночью последовательно льётся один поток данных, и репозиторий с постоянными merge, synthetic full и активными housekeeping-задачами — это уже разные миры.

Некоторые surveillance, media и cold storage-сценарии тоже могут быть допустимы, если профиль записи близок к последовательному. Но автоматически переносить это на любое видеонаблюдение нельзя: конкретная модель диска, его позиционирование и режим работы важнее красивой категории в маркетинге.

Наконец, hyperscale и объектные платформы действительно используют SMR. Но это не аргумент в духе «значит, можно спокойно поставить consumer SMR в домашний RAID 5». В дата-центрах речь часто идёт о другом уровне контроля над стеком хранения, о zoned-aware ПО и об архитектуре, где ограничения SMR учитываются заранее. Western Digital прямо пишет, что для zoned storage нужны специальные программные подходы, а Linux ecosystem подчёркивает, что такие устройства не являются plug-and-play заменой традиционным накопителям.

Device-managed SMR в бытовых массивах и host-managed SMR в дата-центрах — не одно и то же

Это главный источник путаницы. Когда администратор малого офиса или владелец NAS покупает HDD, он почти всегда сталкивается с device-managed SMR, который должен выглядеть и выглядит как обычное блочное устройство. Удобство здесь очевидно: не нужно менять ПО. Но и риски тоже очевидны: накопитель скрывает внутреннюю сложность, а проблемы проявляются в самых неприятных точках — под sustained write и при rebuild.

Host-managed SMR — противоположная история. Там хост знает о зонах, а ПО пишет в них осознанно. Возможны dm-zoned, zonefs и другие элементы zoned ecosystem, но это уже не «обычный RAID из коробки». Поэтому ссылка на enterprise SMR без оговорок почти всегда вводит в заблуждение. Для обычного RAID/NAS без zoned-aware стека CMR остаётся baseline, от которого и нужно отталкиваться.

Как понять, что диск SMR

Проблема в том, что тип записи не всегда виден в карточке товара. Иногда его приходится искать в datasheet, по точной модели, в официальных списках производителя или в support-документации. Сама серия может не быть однозначным показателем: значение имеет конкретный model number.

Рынок уже проходил болезненную путаницу с NAS-дисками. Western Digital после этого развела линейки и отдельно обозначила, что WD Red Plus и WD Red Pro — это CMR, в том числе для более write-intensive SMB-сценариев и ZFS. Seagate, в свою очередь, публикует отдельный официальный список CMR и SMR по моделям. Для RAID это практическая необходимость, а не формальность.

Перед покупкой диска под RAID стоит проверить:

• точную модель, а не только серию;
• тип записи: CMR или SMR;
• класс нагрузки и workload rating;
• позиционирование диска: desktop, archive, NAS, enterprise;
• рекомендации производителя по конкретному сценарию.

CMR и SMR по типовым сценариям

Можно ли смешивать SMR и CMR в одном массиве

Технически массив может собраться и даже пройти инициализацию без видимых проблем. Практически же он будет упираться в наименее предсказуемый диск. При rebuild и sustained write поведение всего массива начнёт определяться слабейшим звеном. Для RAID важна не только одинаковая ёмкость и интерфейс, но и близкий latency-профиль. Поэтому смешивать SMR и CMR в одном массиве не рекомендуется, даже если «всё завелось».

Что делать, если SMR уже куплены

Паниковать и сразу списывать диски не нужно. Но и пытаться упрямо сделать из них универсальную основу для production RAID — тоже плохая стратегия.

Рациональные варианты такие:

• перевести их в роль одиночных backup или archive-дисков;
• использовать вне write-heavy RAID;
• оставить для холодного резерва;
• ограничить сценарий крупными последовательными окнами записи;
• перед production-вводом отдельно протестировать rebuild и латентность под реальной нагрузкой.

Если SMR уже работают в NAS или RAID, стоит хотя бы мониторить время rebuild, отслеживать таймауты и выпадения дисков и планировать переход на CMR при следующем цикле обновления.

Когда брать CMR, а когда можно рассматривать SMR

CMR стоит брать по умолчанию, если массив активный, если есть частые мелкие записи, если речь идёт о NAS, ZFS, mdadm, hardware RAID, если важна предсказуемость rebuild и если это production.

SMR имеет смысл рассматривать, если главная цель — ёмкость и стоимость за терабайт, запись в основном последовательная, данные редко изменяются, сценарий ближе к backup, archive или cold tier и вы понимаете, что не получите поведения CMR. Отдельный случай — специализированный zoned-aware стек, где ограничения SMR не игнорируются, а учитываются в архитектуре.

Вывод

Для большинства обычных RAID- и NAS-сценариев выбирать нужно CMR. Не потому, что SMR «плохой», а потому, что CMR предсказуемее там, где массив работает под нагрузкой, переживает rebuild и должен просто вести себя ровно.

SMR допустим не вообще, а только в правильно подобранных сценариях. Consumer device-managed SMR в традиционном RAID — это компромисс с риском неприятных сюрпризов под sustained write и во время восстановления. Enterprise host-managed SMR — отдельная архитектурная категория, а не оправдание для любой SMR-модели.

Если нужен RAID, который должен просто работать предсказуемо, берите CMR. SMR стоит рассматривать только тогда, когда вы осознанно строите архивный или специализированный сценарий под его ограничения.