Er zijn Btrfs-verbeteringen voorgesteld voor opname in de Linux 6.2-kernel om het schrijfgatprobleem in de RAID 5/6-implementatie op te lossen. De essentie van het probleem komt neer op het feit dat als er een crash optreedt tijdens de opname, het in eerste instantie onmogelijk is om te begrijpen welk blok op welk RAID-apparaat correct is geschreven en waarin de opname niet is voltooid. Als u in deze situatie probeert een RAID te herstellen, kunnen de blokken die overeenkomen met de onderschreven blokken vernietigd worden omdat de status van de RAID-blokken niet gesynchroniseerd is. Dit probleem doet zich voor bij alle RAID1/5/6-arrays waar geen speciale maatregelen zijn genomen om dit effect te bestrijden.
In een RAID-implementatie, zoals RAID1 in btrfs, wordt dit probleem opgelost door checksums in beide kopieën te gebruiken; als er een mismatch is, worden de gegevens eenvoudigweg hersteld vanaf de tweede kopie. Deze aanpak werkt ook als een apparaat onjuiste gegevens begint te verzenden in plaats van een volledige storing.
In het geval van RAID5/6 slaat het bestandssysteem echter geen controlesommen op voor de pariteitsblokken: in een normale situatie wordt de geldigheid van de blokken geverifieerd door het feit dat ze allemaal gecontroleerd zijn, en kan het pariteitsblok gereconstrueerd worden. uit de gegevens. Bij gedeeltelijke opname werkt deze aanpak echter in bepaalde situaties mogelijk niet. In dit geval is het bij het herstellen van een array mogelijk dat blokken die onder een onvolledig record vallen, onjuist worden hersteld.
In het geval van btrfs is dit probleem het meest relevant als de geproduceerde plaat kleiner is dan de streep. In dit geval moet het bestandssysteem een lees-wijzig-schrijfbewerking uitvoeren (lezen-wijzigen-schrijven, RMW). Als hierdoor blokken met onvolledig schrijven worden aangetroffen, kan de RMW-bewerking corruptie veroorzaken die niet wordt gedetecteerd, ongeacht de controlesommen. De ontwikkelaars hebben wijzigingen aangebracht waarbij de RMW-bewerking de controlesom van blokken controleert voordat deze bewerking wordt uitgevoerd, en als het nodig is om gegevens te herstellen, controleert deze ook de controlesom na het opnemen. Helaas leidt dit in een situatie waarin een onvolledige stripe (RMW) wordt geschreven tot extra overhead voor het berekenen van controlesommen, maar verhoogt het de betrouwbaarheid aanzienlijk. Voor RAID6 is dergelijke logica nog niet klaar, maar voor een dergelijke storing in RAID6 is het noodzakelijk dat het schrijven op 2 apparaten tegelijk mislukt, wat minder waarschijnlijk is.
Daarnaast kunnen we van de ontwikkelaars aanbevelingen voor het gebruik van RAID5/6 noteren, waarvan de essentie neerkomt op het feit dat in Btrfs de metadata en het dataopslagprofiel kunnen verschillen. In dit geval kunt u het profiel RAID1 (spiegel) of zelfs RAID1C3 (3 kopieën) gebruiken voor metadata, en RAID5 of RAID6 voor gegevens. Dit zorgt enerzijds voor betrouwbare metadatabescherming en de afwezigheid van een ‘schrijfgat’, en anderzijds voor een efficiënter gebruik van de ruimte, kenmerkend voor RAID5/6. Hierdoor kan metagegevenscorruptie worden vermeden en kan datacorruptie worden gecorrigeerd.
Er kan ook worden opgemerkt dat voor SSD's in Btrfs in kernel 6.2 de asynchrone uitvoering van de "discard" -bewerking standaard wordt geactiveerd (waarbij vrijgemaakte blokken worden gemarkeerd die niet langer fysiek hoeven te worden opgeslagen). Het voordeel van deze modus is hoge prestaties vanwege de effectieve groepering van "weggooi" -bewerkingen in een wachtrij en verdere verwerking van de wachtrij door een achtergrondprocessor. Daarom vertragen normale FS-bewerkingen niet, zoals het geval is bij synchrone " weggooien” omdat blokken vrijkomen en de SSD betere beslissingen kan nemen. Aan de andere kant hoeft u niet langer hulpprogramma's zoals fstrim te gebruiken, omdat alle beschikbare blokken in de FS worden gewist zonder dat extra scannen nodig is en zonder de bewerkingen te vertragen.
Bron: opennet.ru