For the inclusion of Linux kernel 6.2, improvements to Btrfs have been proposed, addressing the 'write hole' issue in RAID 5/6 implementations. The essence of the problem is that if a crash occurs during writing, it is initially impossible to determine which block was correctly written to which RAID device and which was not completed. When attempting to restore RAID under such circumstances, block destruction may occur corresponding to the incomplete blocks, as the state of the RAID blocks becomes desynchronized. This problem arises in any RAID1/5/6 arrays where no special measures are taken to combat this effect.
In implementations of RAID-like RAID1 in btrfs, this problem is resolved by using checksums in both copies; in case of a mismatch, data is simply restored from the second copy. This approach also works if any device starts returning incorrect data instead of a complete failure.
However, in the case of RAID5/6, the filesystem does not store checksums for parity blocks: under normal circumstances, the correctness of blocks is verified by the fact that they all have checksums, and the parity block can be recreated from the data. However, in the case of a partial write, this approach may not work in certain situations. In this case, during the restoration of the array, it is possible that blocks involved in the incomplete write may be restored incorrectly.
I tilfælde af btrfs er dette problem mest relevant, hvis den producerede skrivning er mindre end striben. I dette tilfælde skal filsystemet udføre en læse-modificer-skriv (read-modify-write, RMW) operation. Hvis der støder på blokke med en ufuldstændig skrivning, kan en sådan RMW-operation forårsage ødelæggelser, der ikke vil blive opdaget, uanset checksummere. Udviklerne har indført ændringer, hvor RMW-operationen kontrollerer checksummen af blokke, før der udføres denne operation, og efter behov udfører de også checksum-kontroller efter skrivning i tilfælde af datagendannelse. Desværre medfører det i situationen med en ufuldstændig stribe (RMW) ekstra overhead til beregning af checksummere, men det øger betydeligt pålideligheden. For RAID6 er denne logik endnu ikke klar, men en sådan fejl i RAID6 kræver, at skrivningen mislykkes på to enheder samtidig, hvilket er mindre sandsynligt.
Derudover kan der nævnes anbefalinger fra udviklerne ved brug af RAID5/6, som er baseret på, at i Btrfs kan opbevaringsprofilen for metadata og data være forskellig. Her kan der anvendes en RAID1-profil (spejl) eller endda RAID1C3 (3 kopier) for metadata, mens RAID5 eller RAID6 anvendes til data. Dette sikrer en pålidelig beskyttelse af metadata og fraværet af 'write hole' på den ene side og mere effektiv pladsudnyttelse, karakteristisk for RAID5/6, på den anden. Dette gør det muligt at undgå ødelæggelser i metadataene, mens dataskader kan rettes.
Det kan også nævnes, at for SSD er asynkron udførelse af 'discard'-operationen (mærkning af frigivne blokke, som ikke længere kan opbevares fysisk) aktiveret som standard i Btrfs i kerne 6.2. Fordelen ved denne tilstand er høj ydeevne på grund af effektiv gruppering af 'discard'-operationer i køen og derefter behandling af køen af en baggrundsprocessor, hvilket gør, at normale Filsystemoperationer ikke forsinkes, som i tilfælde med synkron 'discard', mens blokke frigives, og SSD'en kan træffe mere optimale beslutninger. På den anden side vil der ikke længere være behov for at bruge værktøjer som fstrim, da alle tilgængelige blokke vil blive ryddet i Filsystemet uden behov for yderligere scanning og uden at forsinke operationerne.
Kilde: opennet.ru
