Pentru activarea kernel-ului Linux 6.2, s-au propus îmbunătățiri Btrfs, vizând corectarea problemei „write hole” în implementarea RAID 5/6. Problema constă în faptul că, dacă apare o eroare în timpul scrierii, inițial nu este posibil să înțelegem care bloc a fost scris corect pe care dintre dispozitivele RAID și în care scrierea nu a fost finalizată. În cazul unei încercări de recuperare a RAID-ului într-o astfel de situație, poate avea loc distrugerea blocurilor corespunzătoare blocurilor nescrise, deoarece starea blocurilor RAID este dezacordată. Această problemă apare în orice aranjament RAID 1/5/6, unde nu se iau măsuri speciale pentru a combate acest efect.
În implementarea RAID, precum RAID 1 în btrfs, această problemă este rezolvată prin utilizarea sumelor de control în ambele copii; în caz de neconcordanță, datele sunt pur și simplu restaurate din a doua copie. Această abordare se aplică și în cazul în care un dispozitiv începe să returneze date incorecte în loc de o defecțiune completă.
Cu toate acestea, în cazul RAID 5/6, sistemul de fișiere nu păstrează sume de control pentru blocurile de paritate: în situații normale, corectitudinea blocurilor este verificată prin faptul că toate sunt echipate cu o sumă de control, iar blocul de paritate poate fi recreat din date. Totuși, în cazul unei scrieri parțiale, această abordare poate să nu funcționeze în anumite situații. În acest caz, la recuperarea aranjamentului, nu este exclus ca blocurile afectate de scrierea incompletă să fie restaurate incorect.
În cazul btrfs, această problemă este cea mai relevantă atunci când scrierea efectuată este ca mărime mai mică decât stripe-ul. În acest caz, sistemul de fișiere trebuie să efectueze operația de citire-modificare-scriere (read-modify-write, RMW). Dacă întâlnim blocuri cu scriere incompletă, atunci operația RMW poate provoca distrugeri care nu vor fi detectate, în ciuda sumelor de control. Dezvoltatorii au adus modificări prin care operația RMW verifică suma de control a blocurilor înainte de a efectua această operație, iar, în cazul necesității de recuperare a datelor, efectuează și verificarea sumelor de control după scriere. Din păcate, în situația cu o scriere incompletă a stripe-ului (RMW), acest lucru duce la costuri suplimentare pentru calculul sumelor de control, însă crește semnificativ fiabilitatea. Pentru RAID6, această logică nu este încă pregătită, dar, pentru o astfel de defecțiune în RAID6, este necesar ca scrierea să nu reușească pe două dispozitive simultan, ceea ce este mai puțin probabil.
De asemenea, se pot menționa recomandările dezvoltatorilor privind utilizarea RAID5/6, care constau în faptul că, în Btrfs, profilul de stocare pentru metadate și date poate fi diferit. Astfel, se poate utiliza un profil RAID1 (oglindire) sau chiar RAID1C3 (3 copii) pentru metadate, iar pentru date RAID5 sau RAID6. Acest lucru asigură o protecție fiabilă a metadatelor și absența „write hole” pe de o parte și o utilizare mai eficientă a spațiului, caracteristică RAID5/6, pe de altă parte. Acest lucru ajută la evitarea distrugerilor în metadate, iar daunele aduse datelor pot fi corectate.
De asemenea, trebuie menționat că pentru SSD în Btrfs, în kernelul 6.2, va fi activată în mod implicit executarea asincronă a operației „discard” (marcarea blocurilor eliberate, care nu mai trebuie stocate fizic). Avantajul acestui mod este performanța ridicată datorită grupării eficiente a operațiunilor „discard” în coadă și apoi procesarea acesteia de către un gestionator în fundal, astfel încât operațiile normale ale FS nu sunt încetinite, ca în cazul cu „discard” sincron pe măsură ce blocurile sunt eliberate, iar SSD poate lua decizii mai favorabile. Pe de altă parte, nu mai este necesar să se utilizeze utilitare precum fstrim, deoarece toate blocurile disponibile vor fi curățate în FS fără necesitatea unei scanări suplimentare și fără a încetini operațiile.
Sursa: opennet.ro
