Диск отдал не те данные и не сказал об этом: что такое URE

MAATRIX

Диск не всегда ломается со скрежетом и щелчками — иногда он просто в какой-то момент не может корректно отдать один-единственный сектор из миллиардов, и на этом всё: контроллер сообщает об ошибке чтения, а не подсовывает битые данные молча, но легче от этого не намного. У этой ситуации есть имя и паспортная характеристика — URE, Unrecoverable Read Error. Разберёмся, что это на самом деле означает, почему с ростом объёма дисков это стало заметно важнее, чем раньше, и что с этим знанием делать на практике — особенно если у вас RAID.

URE — паспортная вероятность, а не признак поломки

URE (Unrecoverable Read Error) — это характеристика, которая есть у каждого накопителя, механического жёсткого диска в первую очередь, но в своей форме и у SSD тоже. Она описывает статистическую вероятность того, что при чтении определённого объёма данных с диска встретится сектор, который физически невозможно корректно прочитать — то есть встроенная в контроллер диска коррекция ошибок (ECC) не смогла восстановить исходные биты, и диск честно возвращает ошибку чтения вместо данных.

Важно с самого начала развести два разных понятия. Есть отказ диска целиком — механическая поломка, умерший контроллер, диск, который перестаёт определяться в системе. А есть URE — совершенно другая история: диск в остальном исправен, крутится, откликается, все остальные сектора читаются нормально, но именно этот конкретный сектор — нет. Это не «диск умирает», это «у этого диска, как и у любого другого, есть ненулевая вероятность встретить нечитаемый сектор при достаточном объёме чтения», и она указана — или, по крайней мере, должна быть — в полной технической спецификации модели.

Здесь принципиально не гнаться за конкретными цифрами из общих источников: точное значение URE различается у потребительских и корпоративных линеек, у HDD и SSD, у разных производителей и даже у разных ревизий одной модели, и меняется от поколения к поколению. Единственный способ узнать реальное значение для вашего диска — открыть полный datasheet производителя по точной модели (не маркетинговую страницу, там этого параметра обычно нет) и найти там пункт вроде «Non-recoverable Read Errors per Bits Read» или похожий по смыслу. Для целей этой статьи важен не сам порядок величины, а то, что такая характеристика есть у любого диска и она не равна нулю — и именно из этого факта вытекают все практические выводы дальше.

Почему нечитаемый сектор появляется даже на здоровом диске

Интуитивно кажется, что раз диск прошёл проверку SMART и не показывает тревожных счётчиков, то ему можно доверять целиком. На практике это не совсем так, и вот почему.

Плотность записи на современных дисках огромна, а физические носители — что магнитное покрытие пластин HDD, что ячейки флеш-памяти в SSD — не идеальны. Магнитный домен может со временем чуть сместиться, соседняя дорожка при записи может слегка «зацепить» край нужной, ячейка флеш-памяти теряет заряд от времени и температуры, космическое излучение и тепловой шум в редких случаях переворачивают отдельный бит. Встроенная коррекция ошибок в контроллере диска рассчитана на то, чтобы исправлять подавляющее большинство таких сбоев прозрачно для системы — вы никогда не узнаёте, что она сработала. Но у любой схемы коррекции есть предел: если повреждений в одном секторе оказалось больше, чем схема способна восстановить, диск честно сообщает об ошибке чтения вместо того, чтобы отдать испорченные данные как правильные.

Ключевой практический момент — такой сектор совершенно не обязан заранее «засветиться» в счётчиках SMART. Reallocated Sectors Count и Current Pending Sector растут тогда, когда контроллер уже столкнулся с проблемой при записи или предыдущем чтении и как-то на неё среагировал. А сектор, который годами никто не читал (типичная ситуация для редко используемых областей большого диска или архивного раздела), может тихо деградировать и обнаружить себя только при первом реальном обращении — то есть именно тогда, когда он вам понадобится. Диск, который вчера прошёл smartctl -a без единого предупреждения, сегодня может не отдать конкретный сектор — и это не противоречие, а нормальная статистика: SMART отслеживает то, с чем контроллер уже сталкивался, а URE — вероятность столкнуться с тем, чего ещё не было.

Почему объём диска — ключевой фактор для URE

Вероятность события в статистике почти всегда растёт с числом попыток, и URE — не исключение. Паспортная величина URE выражается как вероятность ошибки на определённый объём прочитанных данных. Если этот показатель у диска остаётся примерно на одном уровне (а по факту он улучшается медленно и далеко не в каждом новом поколении дисков), а сам диск при этом становится в разы, а то и в десятки раз ёмче — суммарная вероятность встретить хотя бы одну неисправимую ошибку при полном чтении всего объёма диска соответственно растёт вместе с этим объёмом.

Смысл прост: чем больше данных вы читаете за один проход, тем больше у диска «попыток» столкнуться со своей же паспортной вероятностью ошибки. Прочитать 100 ГБ и прочитать 16 ТБ с точки зрения накопленного риска — принципиально разные события, даже если это один и тот же диск с одной и той же паспортной характеристикой URE. В обычной повседневной работе сервера вы практически никогда не читаете весь диск целиком за один присест — обращения случайны, покрывают горячие данные, а холодные области могут не читаться месяцами. Поэтому URE годами остаётся теоретической строчкой в спецификации, которая никак не проявляется. Но стоит появиться сценарию, где нужно прочитать весь объём диска подряд, — и накопленная вероятность перестаёт быть абстракцией.

RAID-ребилд — момент, когда приходится прочитать всё и сразу

Именно таким сценарием чаще всего оказывается восстановление RAID-массива после отказа диска. Логика ребилда подробно разобрана в статье как RAID-массив ведёт себя при отказе диска, здесь важна конкретная деталь: чтобы восстановить содержимое заменённого диска, контроллеру (программному mdadm, ZFS или аппаратному RAID-контроллеру) нужно прочитать данные со всех оставшихся дисков массива полностью — не выборочно, не только занятые блоки в упрощённом понимании, а весь адресуемый объём, от начала до конца, чтобы восстановить недостающие данные через зеркалирование или контрольные суммы.

Это ровно тот сценарий полного чтения, о котором шла речь выше, — только теперь он происходит не в теории, а на живом массиве, причём в самый неудачный момент. Пока массив в норме, у него есть запас избыточности: даже если где-то на диске притаился нечитаемый сектор, контроллер может восстановить данные из копии или по контрольной сумме и незаметно для вас переназначить проблемный участок. Но диск, отказавший первым, уже выбыл — а значит, запас избыточности исчерпан, и любая дополнительная ошибка чтения на любом из оставшихся дисков в процессе ребилда бьёт по массиву без права на восстановление через избыточность самого RAID. Тому, почему именно фаза ребилда концентрирует риск сильнее, чем сам факт отказа диска, посвящена отдельная статья — ребилд RAID: самый опасный момент в жизни массива. А если вам нужна не только логика, но и прикидка вероятности через формулу с конкретными порядками величин URE из спецификаций — это разобрано на примере RAID 5 и больших дисков в статье почему RAID 5 на больших дисках считают опасным.

Важный нюанс: то, что происходит дальше при встрече с URE во время ребилда, зависит от уровня RAID и конкретного контроллера. В зеркалировании без второго уровня избыточности (RAID 1 без запасной копии, RAID 5 в деградированном режиме) ошибка чтения на выжившем диске обычно означает, что соответствующий блок данных восстановить уже не из чего — контроллер либо прерывает ребилд, либо (что хуже с точки зрения незаметности проблемы) пропускает повреждённый блок и продолжает, оставляя дыру в данных, о которой вы узнаете только когда до неё дойдёт приложение. Ни один из этих вариантов не радует, и оба — прямое следствие того, что в момент ребилда резерва на дополнительный сбой не осталось.

Какие схемы избыточности переживают URE во время ребилда

Раз проблема — в отсутствии запаса на дополнительный сбой именно в момент, когда вероятность его встретить максимальна, практический вывод очевиден: закладывайте схему, которая переживает не только отказ одного диска, но и одну неисправимую ошибку чтения поверх этого отказа.

Обратите внимание: горячий резервный диск (hot spare) сам по себе не решает проблему URE — он лишь ускоряет начало ребилда, но не добавляет запаса избыточности во время самого чтения. И отдельно стоит держать в голове то, о чём часто забывают в момент выбора схемы: RAID любого уровня — это защита от отказа диска, а не резервная копия данных, он не спасает от случайного удаления, шифровальщика или ошибки в приложении.

Регулярные проверки целостности — находите URE заранее, а не во время восстановления

Самый неприятный момент встретить URE — это ребилд без резерва избыточности. Самый безопасный момент встретить ту же самую URE — это плановая проверка на исправном массиве, где резерв ещё есть и контроллер может тихо восстановить проблемный сектор из зеркала или по контрольной сумме, даже не сообщая вам ничего тревожного, кроме строчки в логе.

Именно для этого существует scrubbing (или patrol read, consistency check — в разных системах называется по-разному): периодическое фоновое чтение всего объёма массива целиком, пока он в здоровом состоянии. Это способ намеренно прогнать через себя тот самый полный проход по диску, который иначе случится один раз без предупреждения — во время ребилда.

Для программного RAID на Linux (mdadm) проверка запускается так:

echo check > /sys/block/md0/md/sync_action

Прогресс можно посмотреть там же, где и при обычном ребилде:

cat /proc/mdstat

После завершения стоит проверить счётчик расхождений:

cat /sys/block/md0/md/mismatch_cnt

Ненулевое значение — сигнал разобраться, а не паниковать: часть расхождений на массивах без контрольных сумм на уровне ФС — это нормальный побочный эффект работы файловой системы, а не всегда признак URE. Для ZFS аналогичная операция — zpool scrub tank, и в отличие от mdadm check она не просто ищет расхождения, а сразу восстанавливает повреждённые блоки из избыточности пула, если она есть, благодаря контрольным суммам на уровне файловой системы. Для аппаратных RAID-контроллеров подобная функция обычно называется Patrol Read или Consistency Check и настраивается через утилиту управления контроллером — расписание стоит выставить на регулярную основу, а не оставлять на разовый запуск.

Регулярность здесь важнее разовой проверки: смысл scrubbing в том, чтобы находить URE, пока есть из чего восстановить данные, и делать это достаточно часто, чтобы деградация не успевала накапливаться незамеченной. Разумный ориентир — раз в месяц-полтора для активно используемых массивов, чаще для больших ёмких дисков, где полный проход и так занимает много времени и есть смысл распределить проверку по расписанию с учётом нагрузки на прод. Заодно это хороший повод сверяться с общим состоянием железа — про то, что ещё стоит проверять на сервере регулярно, помимо самого RAID, есть отдельный разбор: проверка железа раз в квартал: SMART и температура.

Частые вопросы