Для включення ядро Linux 6.2 запропоновано покращення Btrfs, що стосуються виправлення проблеми write hole у реалізації RAID 5/6. Суть проблеми зводиться до того, що якщо крах трапився під час запису, спочатку неможливо зрозуміти який блок на якому RAID 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