Btrfs-plibonigoj estis proponitaj por inkludo en la Linukso 6.2-kerno por ripari la skribtruan problemon en la RAID 5/6-efektivigo. La esenco de la problemo venas al la fakto, ke se kraŝo okazas dum registrado, estas komence neeble kompreni, kiu bloko sur kiu RAID-aparato estis skribita ĝuste, kaj en kiu la registrado ne estis finita. Se vi provas restarigi RAID en ĉi tiu situacio, la blokoj respondaj al la subskribitaj blokoj povas esti detruitaj ĉar la stato de la RAID-blokoj estas malsinkronigita. Ĉi tiu problemo okazas en iuj RAID1/5/6 tabeloj kie specialaj rimedoj ne estis prenitaj por kontraŭbatali ĉi tiun efikon.
En RAID-efektivigo, kiel RAID1 en btrfs, tiu problemo estas solvita uzante ĉeksumojn en ambaŭ kopioj; se ekzistas miskongruo, la datenoj estas simple restarigitaj de la dua kopio. Ĉi tiu aliro ankaŭ funkcias se iu aparato komencas sendi malĝustajn datumojn anstataŭ kompleta fiasko.
Tamen, en la kazo de RAID5/6, la dosiersistemo ne stokas kontrolsumojn por la egalecblokoj: en normala situacio, la valideco de la blokoj estas kontrolita per la fakto ke ili estas ĉiuj kontrolsumitaj, kaj la egalecbloko povas esti rekonstruita. de la datumoj. Tamen, en la kazo de parta registrado, ĉi tiu aliro eble ne funkcias en certaj situacioj. En ĉi tiu kazo, dum restarigo de tabelo, eblas, ke blokoj kiuj kategoriiĝas sub nekompleta rekordo estos restarigitaj malĝuste.
En la kazo de btrfs, ĉi tiu problemo estas plej grava se la produktata disko estas pli malgranda ol la strio. En ĉi tiu kazo, la dosiersistemo devas plenumi operacion de legado-modifo-skribi (legi-modifi-skribi, RMW). Se ĉi tio renkontas blokojn kun nekompleta skribo, tiam la RMW-operacio povas kaŭzi korupton, kiu ne estos detektita, sendepende de la ĉeksumoj. La programistoj faris ŝanĝojn, en kiuj la operacio RMW kontrolas la kontrolsumon de blokoj antaŭ ol plenumi ĉi tiun operacion, kaj se necesas restarigi datumojn, ĝi ankaŭ kontrolas la kontrolsumojn post registrado. Bedaŭrinde, en situacio kun skribado de nekompleta strio (RMW), ĉi tio kondukas al plia ŝarĝo por kalkulado de ĉeksumoj, sed signife pliigas fidindecon. Por RAID6, tia logiko ankoraŭ ne estas preta, tamen por tia malsukceso en RAID6 necesas, ke la skribo malsukcesu sur 2 aparatoj samtempe, kio estas malpli verŝajna.
Aldone, ni povas noti rekomendojn por uzi RAID5/6 de la programistoj, kies esenco resumiĝas al la fakto, ke en Btrfs la metadatumoj kaj datumstokado-profilo povas malsami. En ĉi tiu kazo, vi povas uzi la profilon RAID1 (spegulo) aŭ eĉ RAID1C3 (3 kopioj) por metadatenoj, kaj RAID5 aŭ RAID6 por datumoj. Ĉi tio certigas fidindan metadatuman protekton kaj la foreston de "skriba truo", unuflanke, kaj pli efika uzado de spaco, karakterizaĵo de RAID5/6, aliflanke. Ĉi tio permesas eviti korupton de metadatenoj kaj korekti korupton de datumoj.
Oni povas ankaŭ rimarki, ke por SSD-oj en Btrfs en kerno 6.2, la nesinkrona ekzekuto de la operacio "forĵeti" estos aktivigita defaŭlte (markante liberigitajn blokojn, kiuj ne plu bezonas esti fizike stokitaj). La avantaĝo de ĉi tiu reĝimo estas alta rendimento pro la efika grupiĝo de "forĵeti" operacioj en atendovico kaj plua prilaborado de la atendovico per fona procesoro, tial normalaj FS-operacioj ne malrapidiĝas, kiel estas la kazo kun sinkrona " forĵeti" ĉar blokoj estas liberigitaj, kaj la SSD povas fari pli bonajn decidojn. Aliflanke, vi ne plu bezonos uzi ilojn kiel fstrim, ĉar ĉiuj disponeblaj blokoj estos forigitaj en la FS sen bezono de plia skanado kaj sen malrapidigi operaciojn.
fonto: opennet.ru