За активиране на 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
