A kernel engedélyezéséhez Linux A 6.2-es verzió fejlesztéseket javasol a Btrfs fájlrendszerben a RAID 5/6 implementációk „írási lyuk” problémájának kezelésére. A probléma abból fakad, hogy ha írási hiba történik írás közben, kezdetben lehetetlen meghatározni, hogy melyik blokk melyik RAID eszközre lett helyesen írva, és melyik nem. Ha ilyen helyzetben RAID helyreállítási kísérletet tesznek, a ki nem írt blokkoknak megfelelő blokkok megsérülhetnek, mivel a RAID blokk állapota nincs szinkronban. Ez a probléma minden olyan RAID 1/5/6 tömbben előfordul, amely nem valósít meg speciális intézkedéseket a probléma enyhítésére.
A btrfs fájlrendszerben lévő RAID1-hez hasonló RAID implementációkban ezt a problémát úgy oldják meg, hogy mindkét másolaton ellenőrzőösszegeket használnak; eltérés esetén az adatok egyszerűen a második másolatból kerülnek visszaállításra. Ez a megközelítés akkor is működik, ha egy eszköz helytelen adatokat kezd visszaadni a teljes meghibásodás helyett.
A RAID5/6-ban azonban a fájlrendszer nem tárol ellenőrzőösszegeket a paritásblokkokhoz: általában a blokkok helyességét az a tény ellenőrzi, hogy mindegyikhez tartozik-e ellenőrzőösszeg, és a paritásblokk rekonstruálható az adatokból. Részleges írások esetén azonban ez a megközelítés bizonyos helyzetekben kudarcot vallhat. Ebben az esetben a tömb visszaállításakor előfordulhat, hogy a hiányos írás által érintett blokkok helytelenül rekonstruálódnak.
A btrfs esetében ez a probléma akkor a legégetőbb, ha az írás kisebb, mint egy csíkozott blokk. Ebben az esetben a fájlrendszernek olvasási-módosítási-írási (RMW) műveletet kell végrehajtania. Ha ez a művelet hiányos írású blokkokat talál, az RMW művelet olyan sérülést okozhat, amely észrevétlen marad, függetlenül az ellenőrzőösszegektől. A fejlesztők egy olyan változtatást hajtottak végre, hogy az RMW művelet a művelet végrehajtása előtt ellenőrzi a blokk ellenőrzőösszegét, és ha adat-helyreállítás szükséges, akkor az írás után is ellenőrzi az ellenőrzőösszegeket. Sajnos a részleges csíkozott írások (RMW) esetén ez további terhelést jelent az ellenőrzőösszegek kiszámításához, de jelentősen javítja a megbízhatóságot. Ez a logika még nem áll készen a RAID 6-ra, de egy ilyen hiba esetén a RAID 6-ban az írásnak két eszközön kell egyszerre meghiúsulnia, ami kevésbé valószínű.
Ezenkívül figyelemre méltóak a fejlesztők RAID5/6 használatára vonatkozó ajánlásai. Ezen ajánlások lényege, hogy a Btrfs-ben a metaadat- és adattárolási profilok eltérhetnek. Ebben az esetben a metaadatokhoz RAID1 (tükör) vagy akár RAID1C3 (3 másolat) profilt, az adatokhoz pedig RAID5 vagy RAID6 profilt használhat. Ez biztosítja a megbízható metaadat-védelmet és az írási lyukak hiányát, miközben a RAID5/6-ra jellemző hatékonyabb helykihasználást is biztosítja. Ez megakadályozza a metaadatok sérülését, és az adatsérülés javítható.
Azt is érdemes megjegyezni, hogy az aszinkron „eldobás” műveletek (a felszabadított blokkok megjelölése, amelyek fizikailag már nem tárolhatók) alapértelmezés szerint engedélyezve lesznek az SSD-k esetében a Btrfs-ben a 6.2-es kernelben. Ennek a módnak az előnye a nagy teljesítmény, amely a „eldobás” műveletek hatékony várakozási sorba csoportosításának és a sor háttérkezelő általi későbbi feldolgozásának köszönhető. Ez azt jelenti, hogy a normál fájlrendszeri műveletek nem lassulnak le a blokkok felszabadításával, mint a szinkron „eldobás” esetében, és az SSD jobb döntéseket tud hozni. Másrészt nincs szükség olyan segédprogramok használatára, mint az fstrim, mivel az összes elérhető blokk törlődik a fájlrendszerben további szkennelés vagy a műveletek lassítása nélkül.
Forrás: opennet.ru
