За включване в ядрото 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 е необходимо да не успее записът на две устройства, което е по-малко вероятно.
Допълнително могат да бъдат отбелязани препоръките за използване на RAID5/6 от разработчиците, които подсказват, че в Btrfs профилът за съхранение на метаданни и данни може да се различава. Може да бъде използван профил RAID1 (зеркало) или дори RAID1C3 (3 копия) за метаданни, а за данни RAID5 или RAID6. Това осигурява надеждна защита на метаданните и предотвратява проблема с „write hole“ от едната страна, а също така по-ефективно използва пространството, характерно за RAID5/6, от друга. Това позволява да се избягват повреди в метаданните, а повредите в данните могат да бъдат коригирани.
Също така може да се отбележи, че за SSD в Btrfs в ядрото 6.2 ще бъде активирано по подразбиране асинхронното изпълнение на операцията „discard“ (означаване на освободените блокове, които вече не е необходимо да се съхраняват физически). Предимството на този режим е висока производителност благодарение на ефективната групировка на операциите „discard“ в опашка и по-нататъшната обработка на опашката от фонов обработвач, поради което нормалните операции на файловата система не се забавят, както в случая с синхронния „discard“ при освобождаване на блокове, а SSD може да взема по-добри решения. От друга страна, вече не е необходимо да се използват утилити като fstrim, тъй като всички налични блокове ще бъдат изчиствани във файловата система без необходимост от допълнително сканиране и без забавяне на операциите.
Източник: opennet.ru
