Btrfs-i täiustusi on soovitatud lisada Linuxi 6.2 kernelisse, et parandada RAID 5/6 juurutuse kirjutusava probleemi. Probleemi olemus taandub asjaolule, et kui salvestamise ajal tekib krahh, pole esialgu võimalik aru saada, millises RAID-seadmes on õigesti kirjutatud plokk ja millises salvestus ei lõpetatud. Kui proovite selles olukorras RAID-i taastada, võivad kindlustusplokkidele vastavad plokid hävida, kuna RAID-plokkide olek on sünkroonist väljas. See probleem ilmneb kõigis RAID1/5/6 massiivides, kus selle mõjuga võitlemiseks ei ole võetud erimeetmeid.
RAID-rakenduses, nagu RAID1 btrfs-is, lahendatakse see probleem mõlemas koopias kontrollsummade kasutamisega; mittevastavuse korral taastatakse andmed lihtsalt teisest koopiast. See lähenemisviis toimib ka siis, kui mõni seade hakkab täieliku rikke asemel saatma valeandmeid.
RAID5/6 puhul aga failisüsteem paarsusplokkide kontrollsummasid ei salvesta: tavaolukorras kontrollib plokkide kehtivust see, et need kõik on kontrollsummad ja paarsusplokki saab rekonstrueerida. andmetest. Osalise salvestamise puhul ei pruugi see lähenemine aga teatud olukordades toimida. Sel juhul on massiivi taastamisel võimalik, et mittetäieliku kirje alla kuuluvad plokid taastatakse valesti.
Btrfs-i puhul on see probleem kõige olulisem, kui toodetav kirje on ribast väiksem. Sel juhul peab failisüsteem sooritama toimingu loe-muuda-kirjuta (loe-muuda-kirjuta, RMW). Kui see puutub kokku mittetäieliku kirjutamisega plokkidega, võib RMW toiming põhjustada kahjustusi, mida kontrollsummadest hoolimata ei tuvastata. Arendajad on teinud muudatusi, milles RMW toiming kontrollib enne selle toimingu sooritamist plokkide kontrollsummat ja kui on vaja andmeid taastada, siis kontrollib kontrollsummasid ka pärast salvestamist. Kahjuks toob see mittetäieliku triibu (RMW) kirjutamise olukorras kaasa kontrollsummade arvutamise lisakulu, kuid suurendab oluliselt töökindlust. RAID6 jaoks pole selline loogika veel valmis, kuid sellise RAID6 tõrke korral on vaja, et kirjutamine ebaõnnestuks korraga kahes seadmes, mis on vähem tõenäoline.
Lisaks võime märkida arendajate soovitusi RAID5/6 kasutamiseks, mille põhiolemus seisneb selles, et Btrfs-is võivad metaandmed ja andmesalvestusprofiil erineda. Sel juhul saate metaandmete jaoks kasutada profiili RAID1 (peegel) või isegi RAID1C3 (3 koopiat) ja andmete jaoks RAID5 või RAID6. See tagab ühelt poolt usaldusväärse metaandmete kaitse ja “kirjutusava” puudumise ning teiselt poolt RAID5/6-le iseloomuliku tõhusama ruumikasutuse. See võimaldab vältida metaandmete riknemist ja andmete riknemist parandada.
Samuti võib märkida, et kerneli 6.2 Btrfs-i SSD-de puhul aktiveeritakse vaikimisi toimingu "viskamine" asünkroonne täitmine (märgistades vabastatud plokid, mida ei ole enam vaja füüsiliselt salvestada). Selle režiimi eeliseks on kõrge jõudlus tänu tõhusale "viskamise" toimingute rühmitamisele järjekorda ja järjekorra edasisele töötlemisele taustaprotsessori poolt, mistõttu tavalised FS-i toimingud ei aeglustu, nagu sünkroonse " visata ära”, kuna plokid vabanevad, ja SSD saab teha paremaid otsuseid. Teisest küljest ei pea te enam kasutama utiliite, nagu fstrim, kuna kõik saadaolevad plokid tühjendatakse FS-is ilma täiendavat skannimist vajamata ja toiminguid aeglustamata.
Allikas: opennet.ru