Linux Kernel
Dat bleek onlangs verbeteringen aan Btrfs werden voorgesteld voor opname in de Linux 6.2-kernel om het schrijfgatprobleem in RAID 5/6-implementatie op te lossen.
De essentie van het probleem komt erop neer dat als er een crash optreedt tijdens het opnemen, het in eerste instantie onmogelijk is om te begrijpen op welk blok op welk van de RAID-apparaten correct is geschreven en waarop de opname niet is voltooid.
Als u in deze situatie probeert een RAID opnieuw op te bouwen, kunnen de blokken die overeenkomen met de geabonneerde blokken beschadigd raken omdat de status van de RAID-blokken niet synchroon loopt. Dit probleem doet zich voor in elke RAID1/5/6-array waar geen speciale maatregelen zijn genomen om dit effect tegen te gaan.
In een RAID-implementatie zoals RAID1 in btrfs is dit probleem opgelost door controlesommen op beide kopieën te gebruiken, worden de gegevens, als er een mismatch is, eenvoudig hersteld vanaf de tweede kopie. Deze aanpak werkt ook als een apparaat slechte gegevens begint te geven in plaats van volledig uit te vallen.
Echter in het geval van RAID5/6 slaat het bestandssysteem geen controlesommen op voor pariteitsblokken - in een normale situatie wordt de juistheid van de blokken gecontroleerd door het feit dat ze allemaal zijn uitgerust met een controlesom, en het pariteitsblok kan opnieuw worden gemaakt op basis van de gegevens. In het geval van een gedeeltelijke opname werkt deze aanpak in bepaalde situaties echter mogelijk niet. In dit geval, bij het herstellen van de array is het mogelijk dat de blokken achtergelaten in het onvolledige record onjuist worden hersteld.
In het geval van btrfs is dit probleem relevanter als de schrijfbewerking kleiner is dan de streep. In dit geval moet het bestandssysteem een RMW-bewerking (read-modify-write) uitvoeren.
Als het write-in-progress-blokken tegenkomt, kan de RMW-bewerking corruptie veroorzaken die onopgemerkt blijft, ongeacht checksums. De ontwikkelaars hebben wijzigingen aangebracht waarbij de RMW-bewerking de checksum van de blokken verifieert voordat deze bewerking wordt uitgevoerd, en indien nodig voert het gegevensherstel ook een checksum-verificatie uit na het schrijven.
Helaas zorgt dit in een situatie waarin een onvolledige fringe (RMW) wordt geschreven voor extra overhead om de checksums te berekenen, maar verhoogt het de betrouwbaarheid aanzienlijk. Voor RAID6 is dergelijke logica nog niet gereed,
Daarnaast kunnen we de aanbevelingen over het gebruik van RAID5/6 van de ontwikkelaars noteren, waarvan de essentie is dat in Btrfs het profiel voor het opslaan van metadata en data kan verschillen. In dit geval kunt u het profiel RAID1 (mirror) of zelfs RAID1C3 (3 kopieën) gebruiken voor metadata, en RAID5 of RAID6 voor data.
Dit zorgt enerzijds voor een betrouwbare metadatabescherming en de afwezigheid van een "write hole" en anderzijds voor een efficiënter ruimtegebruik, typisch voor RAID5/6. Hierdoor wordt metadatacorruptie voorkomen en kan datacorruptie worden gecorrigeerd.
ook Er kan worden opgemerkt dat voor SSD's op Btrfs in kernel 6.2, la asynchrone uitvoering van de "discard"-bewerking (markeer vrijgemaakte blokken die niet langer fysiek kunnen worden opgeslagen) is standaard ingeschakeld.
La ventaja de esté modus is hoge prestaties dankzij een efficiënte groepering van wegwerpbewerkingen in een wachtrij en naverwerking van de wachtrij door een achtergrondhandler, zodat normale FS-bewerkingen niet worden vertraagd zoals het geval is met synchrone "weggooien" wanneer blokken worden vrijgegeven, en de SSD beter kan maken beslissingen. Aan de andere kant hoef je geen hulpprogramma's zoals fstrim meer te gebruiken, omdat alle beschikbare blokken in de FS worden gewist zonder extra scans en zonder de werking te vertragen.
Tot slot, als u er meer over wilt weten, kunt u de details raadplegen in de volgende link.