Btrfs fejlesztéseket javasoltak a Linux 6.2 rendszermagba való beépítésre, hogy kijavítsák az írási lyuk problémáját a RAID 5/6 megvalósításában. A probléma lényege abban rejlik, hogy ha rögzítés közben összeomlik, akkor kezdetben nem lehet megérteni, hogy melyik blokkra melyik RAID-eszközre íródott helyesen, és melyikben nem fejeződött be a rögzítés. Ha ebben a helyzetben megpróbál visszaállítani egy RAID-et, akkor az aláírt blokkoknak megfelelő blokkok megsemmisülhetnek, mert a RAID blokkok állapota nincs szinkronban. Ez a probléma minden RAID1/5/6 tömbben előfordul, ahol nem tettek különleges intézkedéseket a hatás leküzdésére.
Egy RAID-megvalósításban, mint a RAID1 a btrfs-ben, ezt a problémát úgy oldják meg, hogy mindkét példányban ellenőrzőösszegeket használnak; ha eltérés van, az adatokat egyszerűen visszaállítja a második másolatból. Ez a megközelítés akkor is működik, ha valamelyik eszköz a teljes meghibásodás helyett helytelen adatokat kezd el küldeni.
A RAID5/6 esetében azonban a fájlrendszer nem tárol ellenőrző összegeket a paritásblokkokhoz: normál helyzetben a blokkok érvényességét az ellenőrzi, hogy mindegyik ellenőrző összegzett, és a paritásblokk rekonstruálható. az adatokból. Részleges rögzítés esetén azonban előfordulhat, hogy ez a megközelítés bizonyos helyzetekben nem működik. Ebben az esetben egy tömb visszaállításakor előfordulhat, hogy a hiányos rekord alá tartozó blokkok helytelenül kerülnek visszaállításra.
A btrfs esetében ez a probléma akkor a leglényegesebb, ha az előállított rekord kisebb, mint a csík. Ebben az esetben a fájlrendszernek olvasás-módosítás-írás műveletet kell végrehajtania (olvasás-módosítás-írás, RMW). Ha ez nem teljes írású blokkokat talál, akkor az RMW művelet olyan sérülést okozhat, amelyet a rendszer nem észlel, függetlenül az ellenőrző összegektől. A fejlesztők olyan változtatásokat vezettek be, amelyekben az RMW művelet e művelet végrehajtása előtt ellenőrzi a blokkok ellenőrző összegét, és ha szükséges az adatok visszaállítása, akkor a rögzítés után is ellenőrzi az ellenőrző összegeket. Sajnos egy hiányos csík (RMW) írásakor ez többletköltséget jelent az ellenőrző összegek kiszámításához, de jelentősen növeli a megbízhatóságot. A RAID6 esetében ez a logika még nem áll készen, azonban a RAID6 ilyen meghibásodásához szükséges, hogy az írás egyszerre 2 eszközön sikertelen legyen, ami kevésbé valószínű.
Emellett a fejlesztők RAID5/6 használatára vonatkozó ajánlásokat is megjegyezhetünk, amelyek lényege, hogy a Btrfs-ben a metaadatok és az adattárolási profil eltérhet. Ebben az esetben a RAID1 (tükör) vagy akár a RAID1C3 (3 másolat) profilt használhatja a metaadatokhoz, és a RAID5 vagy RAID6 profilt az adatokhoz. Ez egyrészt megbízható metaadatvédelmet és „írási lyukak” hiányát, másrészt a RAID5/6-ra jellemző hatékonyabb helykihasználást biztosítja. Ez lehetővé teszi a metaadat-sérülések elkerülését és az adatsérülések kijavítását.
Azt is megjegyzendő, hogy a 6.2-es kernel Btrfs-ben lévő SSD-k esetében a „discard” művelet aszinkron végrehajtása alapértelmezés szerint aktiválódik (megjelöli a felszabadult blokkokat, amelyeket már nem kell fizikailag tárolni). Ennek az üzemmódnak az előnye a nagy teljesítmény a „eldobási” műveletek hatékony csoportosítása a sorban és a sor háttérprocesszor általi további feldolgozása miatt, ezért a normál FS műveletek nem lassulnak le, mint a szinkron „ dobja el”, ahogy a blokkok felszabadulnak, és az SSD jobb döntéseket hozhat. Másrészt nem kell többé olyan segédprogramokat használnia, mint az fstrim, mivel az összes elérhető blokk törlődik az FS-ben anélkül, hogy további vizsgálatra lenne szükség, és a műveletek lelassítása nélkül.
Forrás: opennet.ru