Maboresho ya Btrfs yamependekezwa ili kujumuishwa kwenye Linux 6.2 kernel ili kurekebisha tatizo la "write hole" katika utekelezaji wa RAID 5/6. Kiini cha tatizo kinakuja kwa ukweli kwamba ikiwa ajali hutokea wakati wa kurekodi, awali haiwezekani kuelewa ni kizuizi gani ambacho kifaa cha RAID kiliandikwa kwa usahihi, na ambayo kurekodi haikukamilika. Ukijaribu kurejesha RAID katika hali hii, vizuizi vinavyolingana na vizuizi vilivyoandikwa chini vinaweza kuharibiwa kwa sababu hali ya vizuizi vya RAID haijasawazishwa. Tatizo hili hutokea katika safu yoyote ya RAID1/5/6 ambapo hatua maalum hazijachukuliwa ili kupambana na athari hii.
Katika utekelezaji wa RAID, kama RAID1 katika btrfs, shida hii inatatuliwa kwa kutumia cheki katika nakala zote mbili; ikiwa kuna kutolingana, data inarejeshwa tu kutoka kwa nakala ya pili. Mbinu hii pia inafanya kazi ikiwa kifaa fulani kitaanza kutuma data isiyo sahihi badala ya kutofaulu kabisa.
Hata hivyo, katika kesi ya RAID5/6, mfumo wa faili hauhifadhi hundi kwa vitalu vya usawa: katika hali ya kawaida, uhalali wa vitalu unathibitishwa na ukweli kwamba wote ni checksummed, na kizuizi cha usawa kinaweza kujengwa upya. kutoka kwa data. Hata hivyo, katika kesi ya kurekodi sehemu, mbinu hii haiwezi kufanya kazi katika hali fulani. Katika kesi hii, wakati wa kurejesha safu, inawezekana kwamba vitalu vinavyoanguka chini ya rekodi isiyo kamili vitarejeshwa vibaya.
Kwa upande wa btrfs, tatizo hili linafaa zaidi ikiwa rekodi inayotolewa ni ndogo kuliko mstari. Katika kesi hii, mfumo wa faili lazima ufanye operesheni ya kusoma-kurekebisha-kuandika (soma-rekebisha-andika, RMW). Ikiwa hii itakumbana na uandishi usio kamili, basi operesheni ya RMW inaweza kusababisha ufisadi ambao hautatambuliwa, bila kujali hesabu za hundi. Waendelezaji wamefanya mabadiliko ambayo operesheni ya RMW inakagua hundi ya vitalu kabla ya kufanya operesheni hii, na ikiwa ni muhimu kurejesha data, pia huangalia hundi baada ya kurekodi. Kwa bahati mbaya, katika hali ya kuandika mstari usio kamili (RMW), hii inasababisha ziada ya ziada kwa ajili ya kuhesabu hundi, lakini kwa kiasi kikubwa huongeza kuegemea. Kwa RAID6, mantiki hiyo bado haijawa tayari, hata hivyo, kwa kushindwa vile katika RAID6, ni muhimu kwamba kuandika kushindwa kwenye vifaa 2 mara moja, ambayo ni uwezekano mdogo.
Zaidi ya hayo, tunaweza kutambua mapendekezo ya kutumia RAID5/6 kutoka kwa wasanidi programu, ambayo kiini chake ni kwamba katika Btrfs metadata na wasifu wa hifadhi ya data unaweza kutofautiana. Katika kesi hii, unaweza kutumia wasifu RAID1 (kioo) au hata RAID1C3 (nakala 3) kwa metadata, na RAID5 au RAID6 kwa data. Hii inahakikisha ulinzi wa metadata wa kuaminika na kutokuwepo kwa "shimo la kuandika," kwa upande mmoja, na matumizi bora zaidi ya nafasi, tabia ya RAID5/6, kwa upande mwingine. Hii inaruhusu uharibifu wa metadata kuepukwa na uharibifu wa data unaweza kusahihishwa.
Inaweza pia kuzingatiwa kuwa kwa SSD katika Btrfs kwenye kernel 6.2, utekelezaji wa asynchronous wa operesheni ya "tupa" itaamilishwa kwa chaguo-msingi (kuashiria vitalu vilivyoachiliwa ambavyo havihitaji tena kuhifadhiwa kimwili). Faida ya hali hii ni utendaji wa juu kwa sababu ya uwekaji mzuri wa shughuli za "tupa" kwenye foleni na usindikaji zaidi wa foleni na kichakataji cha mandharinyuma, ndiyo sababu shughuli za kawaida za FS hazipunguzi, kama ilivyo kwa synchronous " tupaβ kwani vizuizi vinaachiliwa, na SSD inaweza kufanya maamuzi bora. Kwa upande mwingine, hautahitaji tena kutumia huduma kama fstrim, kwani vizuizi vyote vinavyopatikana vitafutwa katika FS bila hitaji la skanning ya ziada na bila kupunguza kasi ya utendakazi.
Chanzo: opennet.ru