Linux Kernel
Наскоро беше разкрито, че подобренията на Btrfs бяха предложени за включване в ядрото на Linux 6.2 за коригиране на проблема с дупката за запис в изпълнението на RAID 5/6.
Същността на проблема се свежда до факта, че ако възникне срив по време на запис, първоначално е невъзможно да се разбере кой блок на кое от RAID устройствата е записано правилно и на кой запис не е завършен.
Ако се опитате да възстановите RAID в тази ситуация, блоковете, съответстващи на абонираните блокове, може да се повредят, тъй като състоянието на RAID блоковете не е синхронизирано. Този проблем възниква във всеки RAID1/5/6 масив, където не са взети специални мерки за борба с този ефект.
При изпълнение на RAID като RAID1 в btrfs този проблем е решен чрез използване на контролни суми и на двете копия, ако има несъответствие, данните просто се възстановяват от второто копие. Този подход работи и ако някое устройство започне да дава лоши данни, вместо да се повреди напълно.
Въпреки това, в случай на RAID5/6, файловата система не съхранява контролни суми за блокове за паритет - в нормална ситуация коректността на блоковете се проверява от факта, че всички те са оборудвани с контролна сума и блокът за паритет може да бъде пресъздаден от данните. Въпреки това, в случай на частично записване, този подход може да не работи в определени ситуации. В такъв случай, при възстановяване на масива е възможно това блоковете, останали в непълния запис се възстановяват неправилно.
В случай на btrfs, този проблем е по-уместен, ако възникващият запис е по-малък от лентата. В този случай файловата система трябва да извърши операция за четене-промяна-запис (RMW).
Ако срещне блокове в процес на запис, операцията RMW може да причини повреда, която няма да бъде открита, независимо от контролните суми. Разработчиците са направили промени, при които операцията RMW проверява контролната сума на блоковете, преди да извърши тази операция, и ако е необходимо, възстановяването на данни също извършва проверка на контролната сума след запис.
За съжаление, в ситуация, в която е записана непълна периферия (RMW), това създава допълнителни разходи за изчисляване на контролните суми, но значително увеличава надеждността. За RAID6 такава логика все още не е готова,
Освен това можем да отбележим препоръките за използването на RAID5/6 от разработчиците, чиято същност е, че в Btrfs профилът за съхранение на метаданни и данни може да се различава. В този случай можете да използвате профила RAID1 (огледален) или дори RAID1C3 (3 копия) за метаданни и RAID5 или RAID6 за данни.
Това гарантира надеждна защита на метаданните и липса на "дупка за запис", от една страна, и по-ефективно използване на пространството, характерно за RAID5/6, от друга. Това предотвратява повредата на метаданните и повредата на данните може да бъде коригирана.
също Може да се отбележи, че за SSD на Btrfs в ядрото 6.2, la асинхронно изпълнение на операцията "discard". (маркиране на освободени блокове, които вече не могат да се съхраняват физически) ще бъде включено по подразбиране.
Предимството на това режимът е с висока производителност поради ефективно групиране на операции за изхвърляне в опашка и последваща обработка на опашката от фонов манипулатор, така че нормалните FS операции не се забавят, както е в случая със синхронното „изхвърляне“, тъй като блоковете се освобождават, и SSD може да направи по-добре решения. От друга страна, вече няма да е необходимо да използвате помощни програми като fstrim, тъй като всички налични блокове ще бъдат изтрити във FS без необходимост от допълнително сканиране и без забавяне на операциите.
И накрая, ако имате интерес да научите повече за него, можете да се консултирате с подробностите в следната връзка.