Să aveți un weekend excelent! Vă invităm la o lecție demo gratuită , care va fi susținută de Andrei Buranov — specialist în sisteme UNIX la Mail.Ru Group. De asemenea, publicăm un articol de Jonathan Corbet — Editor Executiv la LWN.net.
Sistemele de fișiere jurnalizate promit să elibereze administratorii de sistem de problemele cu deteriorarea discului în caz de defectare a sistemului. Chiar și fără a lansa verificarea integrității sistemului de fișiere. Totuși, în realitate, lucrurile sunt puțin mai complicate. Așa cum sugerează o discuție recentă, este posibil ca acestea să fie chiar mai confuze decât cred mulți dintre noi, deoarece asigurarea integrității sistemelor de fișiere jurnalizate afectează performanța.
Un sistem de fișiere, precum ext3, utilizează o zonă distinctă pe disc, numită jurnal. Atunci când se fac modificări ale metadatelor sistemului de fișiere, aceste modificări sunt mai întâi înregistrate în jurnal fără a modifica restul sistemului de fișiere. După ce toate modificările sunt înregistrate în jurnal, acesta primește un „bloc de comitere“, care indică finalizarea tranzacției. Și doar după ce blocul de comitere este înregistrat, tranzacția este confirmată, iar metadatele modificate sunt scrise pe disc. Dacă sistemul se oprește în vreun moment, informațiile din jurnal pot fi utilizate pentru a încheia în siguranță lucrarea și a evita deteriorarea sistemului de fișiere din cauza actualizării doar a unei părți a metadatelor.
Totuși, există o problemă: codul sistemului de fișiere, înainte de a scrie blocul de comitere, trebuie să fie absolut sigur că toată informația despre tranzacție a fost deja transferată în jurnal. Pur și simplu înregistrarea operațiunilor în ordinea corectă nu este suficientă — unitățile moderne au cache-uri interne mari și reordonizează operațiunile pentru a îmbunătăți performanța. De aceea, înainte de blocul de comitere, este necesar să se indice explicit transferul tuturor datelor jurnalizate pe disc. Dacă blocul de comitere este înregistrat mai devreme, jurnalul poate fi corupt. Pentru a rezolva această problemă, se folosesc bariere. Practic, o barieră interzice înregistrarea oricăror blocuri după barieră, până când toate blocurile înregistrate înainte de barieră sunt transferate pe disc. Folosind bariere, sistemele de fișiere garantează consistența structurilor de fișiere.
Dar există încă o problemă: sistemele de fișiere ext3 și ext4 nu folosesc bariere în mod implicit. Opțiunea există, dar dacă administratorul nu le activează explicit, aceste sisteme de fișiere funcționează fără bariere, deși în anumite distribuții (de exemplu, SUSE) valorile implicite sunt altele. Eric Sandeen a decis recent că această situație trebuie schimbată și , care modifică setările implicite pentru ext3 și ext4. Și atunci a început o dezbatere aprinsă.
Andrew Morton , de ce valoarea implicită este exact așa:
Data trecută, când am încercat să facem această modificare, performanța a scăzut cu 30% la multe sarcini, așa că am aruncat toate aceste patch-uri. Cred că nu ne putem permite acest lucru și să încetinim atât de grav toate mașinile...
Nu există soluții perfecte aici, iar eu tind să nu deranjez acest câine adormit și să las parametrii implici pe seama dezvoltatorilor distribuțiilor.
Prin urmare, în mod implicit, barierele sunt dezactivate, deoarece acestea influențează serios performanța. În plus, sistemele de fișiere pot fi utilizate cu succes fără bariere. Raportările de deteriorare a sistemului de fișiere ext3 sunt puține și rare.
Dar nu este vorba doar de noroc. Ted Ts’o este faptul că jurnalul ext3 / ext4 este de obicei plasat continuu. În primul rând, driverul sistemului de fișiere încearcă să creeze un jurnal continuu. În al doilea rând, jurnalul este, de obicei, creat simultan cu sistemul de fișiere, când este ușor să găsim un spațiu continuu. Continuitatea și ordonarea sunt utile nu doar pentru performanță, ci și pentru a preveni reordonarea. De obicei, blocul de commit va fi plasat imediat după celelalte date din jurnal, astfel că discul nu are motive să reordoneze. Blocul de commit este scris pe disc imediat după celelalte înregistrări din jurnal.
Cu toate acestea, nimeni nu afirmă că așa va fi mereu. Discurile pot acționa diferit. În plus, jurnalul este un buffer circular. Așadar, când o tranzacție este înregistrată la sfârșitul jurnalului, blocul de comitere poate fi în parte anterioară, înaintea altor înregistrări din jurnal. Deci, riscul de corupție este întotdeauna prezent. De fapt, Chris Mason are pentru aceasta . Nu există îndoială că munca fără bariere este mai puțin sigură decât cu ele.
Dacă sunteți pregătiți să acceptați o scădere a performanței, atunci puteți activa barierele. În acel caz, desigur, când sistemul dumneavoastră de fișiere nu se bazează pe LVM (așa cum se întâmplă în unele distribuții implicit). Se pare că device mapper nu suportă bariere. În celelalte cazuri, ar fi bine să reduceți scăderea performanței. Și, se pare, acest lucru se poate face.
Implementarea curentă ext3 (când barierele sunt activate) execută următoarea secvență de operații pentru fiecare tranzacție:
Datele sunt scrise în jurnal
Se execută bariera
Se scrie blocul de comitere
Se execută următoarea barieră
Ulterior, metadatele sunt scrise pe disc
În ext4, prima barieră (pasul 2) poate fi omisă, deoarece sistemul de fișiere ext4 suportă checksum-uri în jurnal.
Dacă datele jurnalului și blocul de comitere sunt rearanjate, iar operația este întreruptă în urma unei erori, atunci checksum-ul jurnalului nu va corespunde cu cel stocat în blocul de comitere, iar tranzacția va fi anulată.
Chris Mason , că ar fi „în general sigur” să eliminați această barieră și în ext3, cu excepția posibilelor cazuri când jurnalul ajunge la capăt și începe să se scrie din nou de la început.
O altă idee pentru a accelera funcționarea este de a amâna operațiile cu bariere atunci când este posibil. Dacă nu există o necesitate stringentă de a scrie imediat datele pe disc, atunci se pot crea mai multe tranzacții în jurnal, și să se scrie pe disc cu o singură barieră.
De asemenea, există un anumit potențial de îmbunătățire prin ordonarea atentă a operațiunilor, astfel încât barierele (care sunt de obicei implementate sub formă de cereri „scrie toate operațiile amânate pe disc”) să nu forțeze scrierea blocurilor care nu necesită ordonare.
Se pare că a sosit momentul să ne gândim cum să facem costul barierelor acceptabil. Ted Tso pare să :
Cred că ar trebui să includem bariere în ext3/4 și apoi să lucrăm la reducerea cheltuielilor indirecte în ext4/jbd2. Probabil că majoritatea sistemelor nu operează în condiții asemănătoare cu cele folosite de Chris pentru a demonstra problema și securitatea sistemului de fișiere ar trebui să fie o prioritate.
Cuvântul bun simț îmi spune că acest câine nu mai doarme și, probabil, va latra pentru o vreme. Aceasta poate provoca îngrijorare în rândul unor vecini, dar este mai bine decât să o lași să muște.
Interesat să dezvoltați în această direcție? Înscrieți-vă pentru un demo gratuit și participați la transmisiune , care va fi condusă de Pavel Vikiriuk — operator de comunicații MVNO, inginer DevOps.
Sursa: habr.com
