До свиданья наш ласковый миша, часть 2

Про проблемы mdadm в современных реалиях мы уже писали, тогда это касалось такого явления, как bitrot (битовое гниение). Но на этом проблемы mdadm не заканчиваются и когда снова и снова видишь рекомендации использовать этот тип массивов как хранилище виртуальных машин, скажем для Proxmox, то начинает дергаться глаз.

Сегодня мы поговорим о более серьезной проблеме - O_DIRECT – флаге прямой записи на блочное устройство, минуя страничный кеш системы.

Этот флаг чаще всего используется СУБД, которые имеют свой кеш и хотят избежать двойного кеширования, а также виртуальными машинами для ускорения операций ввода вывода.

1️⃣ Самая распространенная ошибка при использовании O_DIRECT совместно с mdadm – это ошибка выравнивания. O_DIRECT требует, чтобы блоки записи были выровнены согласно страницам памяти (4 КБ), в то время как mdadm требует выравнивания данных по размеру блока чередования (chunk).

При этом файловая система ничего не знает о внутреннем устройстве RAID, для нее это просто виртуальное блочное устройство. А mdadm не контролирует процесс записи на уровне файловой системы и приложения.

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

Данная ошибка может приводить к краху приложения или всей операционной системы, также она может оказаться фатальной для всего массива, если он находится в состоянии ресинхронизации.

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

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

2️⃣ Вторая проблема mdadm и O_DIRECT – это тихое повреждение данных. Как мы уже говорили, при наличии флага прямой записи mdadm не контролирует содержимое буфера, а передает его на все входящие в массив дисковые устройства.

И если в процессе записи данный буфер будет изменен (а приложения могут менять его содержимое), то мы имеем ненулевой шанс того, что на разные диски будет записан разный набор данных.

Причем сам mdadm это никак не контролирует, не отражает в логах и считает такой массив синхронизированным.

Чаще всего с подобной проблемой можно столкнуться во время живой миграции, что в лучшем случае приводит к сбою в работе мигрирующей машины, в худшем – к повреждению виртуального диска, часто – незаметному.

Данные проблемы в принципе нерешаемы, так как требуют серьезной переработки или mdadm или O_DIRECT, что ни те, ни другие делать не собираются.

❓ А как обстоят дела в других реализациях? Ровно тем же самым проблемам подвержены LVM RAID и DRBD. Все это достаточно старые технологии и причины проблем там те же самые, что и у mdadm.

👉 В то же время современные файловые системы включающие в себя функции RAID, такие как ZFS или btrfs от данных проблем свободны. Да, там тоже были свои сложности при поддержке O_DIRECT, но фатальных проблем с ним они не имели.

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

Также такие файловые системы самостоятельно управляют записью на физические устройства и контролируют содержимое буфера прямой записи, если в процессе записи буфер будет изменен, то изменения будут гарантированно записаны на все физические устройства.

Таким образом мы снова видим, что mdadm значительно устарел и уже не может служить надежным хранилищем для ваших данных.