В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Для включения ядро Linux 6.2 предложены улучшения Btrfs, касающиеся исправления проблемы "write hole" в реализации RAID 5/6. Суть проблемы сводится к тому, что если крах случился во время записи, изначально невозможно понять какой блок на каком из устройств RAID записался корректно, а в каком запись не была завершена. В случае попытки восстановления RAID в подобной ситуации может произойти разрушение блоков, соответствующих недозаписанным блокам, поскольку состояние блоков RAID рассинхронизиорвано. Эта проблема возникает в любых массивах RAID1/5/6, где не принято специальных мер для борьбы с подобным эффектом.
В реализации RAID, наподобие RAID1 в btrfs, эта проблема решается использованием контрольных сумм в обеих копиях, при несовпадении данные просто восстанавливаются из второй копии. Этот подход также срабатывает если какое-то устройство начинает отдавать некорректные данные вместо полного отказа.
Однако в случае RAID5/6 файловая система не хранит контрольные суммы для блоков чётности: в нормальной ситуации корректность блоков проверяется тем фактом, что они все снабжены контрольной суммой, а блок чётности можно воссоздать из данных. Однако в случае частичной записи этот подход в определённых ситуациях может не сработать. В этом случае, при восстановлении массива не исключено, что блоки, попавшие под незавершённую запись, окажутся восстановлены некорректно.
В случае btrfs эта проблема наиболее актуальна, если производимая запись по размеру меньше страйпа. При этом файловая система должна выполнить операцию чтения-модификации-записи (read-modify-write, RMW). Если при этом попадутся блоки с незавершённой записью, в таком случае операция RMW может вызвать разрушения, которые не будут обнаружены, невзирая на контрольные суммы. Разработчики внесли изменения, при которых операция RMW проверяет контрольную сумму блоков до того как производить данную операцию, а при необходимости восстановления данных выполняет и проверку контрольных сумм после записи. К сожалению, в ситуации с записью неполного страйпа (RMW) это ведёт к дополнительным накладным расходам на вычисление контрольных сумм, однако значительно повышает надёжность. Для RAID6 такая логика пока не готова, однако для такого отказа в RAID6 необходимо чтобы запись не удалась на сразу 2 устройствах, что менее вероятно.
Дополнительно можно отметить рекомендации по использованию RAID5/6 от разработчиков, суть которых сводится к тому, что в Btrfs профиль хранения метаданных и данных может отличаться. При этом можно использовать профиль RAID1 (зеркало) или даже RAID1C3 (3 копии) для метаданных, а для данных RAID5 или RAID6. При этом обеспечивается надёжная защита метаданных и отсутствие "write hole" с одной стороны и более эффективное использование места, характерное для RAID5/6, с другой. Это позволяет избегать разрушений в метаданных, а повреждения данных могут быть исправлены.
Также можно отметить, что для SSD в Btrfs в ядре 6.2 будет активировано по умолчанию асинхронное выполнение операции "discard" (пометка освобождённых блоков, которые уже можно не хранить физически). Достоинством этого режима является высокая производительность из-за эффективной группировки операций "discard" в очереди и далее обработки очереди фоновым обработчиком, из-за чего нормальные операции ФС не замедляются, как в случае с синхронным "discard" по мере освобождения блоков, а SSD может принимать более удачные решения. С другой стороны, более не потребуется использовать утилиты типа fstrim, поскольку все доступные блоки будут очищаться в ФС без необходимости дополнительного сканирования и без замедления операций.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://www.phoronix.com/news/...)
- OpenNews: Для Btrfs представлена асинхронная реализация DISCARD
- OpenNews: Новая ФС Bcachefs, сочетающая функциональность btrfs/zfs с производительностью ext4/xfs
- OpenNews: Проблема с повреждением разделов Ext4 оказалась в md-raid0
- OpenNews: Релиз OpenZFS 2.1 с поддержкой dRAID
- OpenNews: Доступен mdadm 4.2, инструментарий для управления программным RAID в Linux
Похожие новости:
- Седьмое обновление стартовых наборов ALT p10
- Уязвимости в ядре Linux, удалённо эксплуатируемые через Bluetooth
- Релиз ядра Linux 6.1
- CERN и Fermilab переключаются на использование AlmaLinux
- Выпуск Green Linux, редакции Linux Mint для российских пользователей
- В ядро Linux 6.2 войдёт подсистема для ускорителей вычислений
- Выпуск дистрибутива EuroLinux 9.1, совместимого с RHEL
- Выпуск дистрибутива Oracle Linux 9.1
- Для Linux предложена файловая система Composefs
- Релиз дистрибутива Rocky Linux 9.1, развиваемого основателем CentOS
Теги для поиска: #_btrfs, #_raid, #_linux
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Ноя 21:15
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Для включения ядро Linux 6.2 предложены улучшения Btrfs, касающиеся исправления проблемы "write hole" в реализации RAID 5/6. Суть проблемы сводится к тому, что если крах случился во время записи, изначально невозможно понять какой блок на каком из устройств RAID записался корректно, а в каком запись не была завершена. В случае попытки восстановления RAID в подобной ситуации может произойти разрушение блоков, соответствующих недозаписанным блокам, поскольку состояние блоков RAID рассинхронизиорвано. Эта проблема возникает в любых массивах RAID1/5/6, где не принято специальных мер для борьбы с подобным эффектом. В реализации RAID, наподобие RAID1 в btrfs, эта проблема решается использованием контрольных сумм в обеих копиях, при несовпадении данные просто восстанавливаются из второй копии. Этот подход также срабатывает если какое-то устройство начинает отдавать некорректные данные вместо полного отказа. Однако в случае RAID5/6 файловая система не хранит контрольные суммы для блоков чётности: в нормальной ситуации корректность блоков проверяется тем фактом, что они все снабжены контрольной суммой, а блок чётности можно воссоздать из данных. Однако в случае частичной записи этот подход в определённых ситуациях может не сработать. В этом случае, при восстановлении массива не исключено, что блоки, попавшие под незавершённую запись, окажутся восстановлены некорректно. В случае btrfs эта проблема наиболее актуальна, если производимая запись по размеру меньше страйпа. При этом файловая система должна выполнить операцию чтения-модификации-записи (read-modify-write, RMW). Если при этом попадутся блоки с незавершённой записью, в таком случае операция RMW может вызвать разрушения, которые не будут обнаружены, невзирая на контрольные суммы. Разработчики внесли изменения, при которых операция RMW проверяет контрольную сумму блоков до того как производить данную операцию, а при необходимости восстановления данных выполняет и проверку контрольных сумм после записи. К сожалению, в ситуации с записью неполного страйпа (RMW) это ведёт к дополнительным накладным расходам на вычисление контрольных сумм, однако значительно повышает надёжность. Для RAID6 такая логика пока не готова, однако для такого отказа в RAID6 необходимо чтобы запись не удалась на сразу 2 устройствах, что менее вероятно. Дополнительно можно отметить рекомендации по использованию RAID5/6 от разработчиков, суть которых сводится к тому, что в Btrfs профиль хранения метаданных и данных может отличаться. При этом можно использовать профиль RAID1 (зеркало) или даже RAID1C3 (3 копии) для метаданных, а для данных RAID5 или RAID6. При этом обеспечивается надёжная защита метаданных и отсутствие "write hole" с одной стороны и более эффективное использование места, характерное для RAID5/6, с другой. Это позволяет избегать разрушений в метаданных, а повреждения данных могут быть исправлены. Также можно отметить, что для SSD в Btrfs в ядре 6.2 будет активировано по умолчанию асинхронное выполнение операции "discard" (пометка освобождённых блоков, которые уже можно не хранить физически). Достоинством этого режима является высокая производительность из-за эффективной группировки операций "discard" в очереди и далее обработки очереди фоновым обработчиком, из-за чего нормальные операции ФС не замедляются, как в случае с синхронным "discard" по мере освобождения блоков, а SSD может принимать более удачные решения. С другой стороны, более не потребуется использовать утилиты типа fstrim, поскольку все доступные блоки будут очищаться в ФС без необходимости дополнительного сканирования и без замедления операций. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Ноя 21:15
Часовой пояс: UTC + 5