{"id":98090,"date":"2020-10-24T02:42:38","date_gmt":"2020-10-24T00:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux"},"modified":"2020-11-18T00:58:48","modified_gmt":"2020-11-17T22:58:48","slug":"ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Stocare sustenabil\u0103 a datelor \u0219i API-uri de fi\u0219iere Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Eu, explor\u00e2nd rezilien\u021ba stoc\u0103rii datelor \u00een sistemele cloud, am decis s\u0103 m\u0103 testez, s\u0103 m\u0103 asigur c\u0103 \u00een\u021beleg conceptele de baz\u0103. Eu am \u00eenceput prin a citi specifica\u021bia NVMe<\/a><\/noindex> pentru a \u00een\u021belege ce garan\u021bii referitoare la stocarea rezistent\u0103 a datelor (adic\u0103 garan\u021bii c\u0103 datele vor fi accesibile dup\u0103 o defec\u021biune a sistemului) ne ofer\u0103 disk-urile NVMe. Am ajuns la urm\u0103toarele concluzii principale: trebuie s\u0103 consideri datele ca fiind corupte din momentul \u00een care a fost dat\u0103 comanda de scriere a datelor \u0219i p\u00e2n\u0103 la momentul \u00een care scrierea lor pe suportul de informa\u021bii este finalizat\u0103. Totu\u0219i, \u00een majoritatea programelor de scriere a datelor, se folosesc \u00een mod lini\u0219tit apeluri la sistem.<\/p>\n

\u00cen acest material, explorez mecanismele de stocare rezistent\u0103 a datelor oferite de API-urile de fi\u0219iere Linux. Se pare c\u0103 totul ar trebui s\u0103 fie simplu: programul apeleaz\u0103 comanda write()<\/code>, iar dup\u0103 ce aceast\u0103 comand\u0103 este finalizat\u0103, datele vor fi salvate \u00een siguran\u021b\u0103 pe disk. Dar write()<\/code> doar copiaz\u0103 datele aplica\u021biei \u00een cache-ul nucleului, situat \u00een memoria RAM. Pentru a obliga sistemul s\u0103 scrie datele pe disk, trebuie s\u0103 folose\u0219ti c\u00e2teva mecanisme suplimentare.<\/p>\n

\"Stocare<\/a><\/noindex><\/p>\n

\u00cen general, acest material reprezint\u0103 un set de note referitoare la ceea ce am \u00eenv\u0103\u021bat pe tema care m\u0103 intereseaz\u0103. Dac\u0103 ar fi s\u0103 rezum cel mai important aspect, ar fi c\u0103 pentru a organiza stocarea rezistent\u0103 a datelor, trebuie s\u0103 folose\u0219ti comanda fdatasync()<\/code> sau s\u0103 deschizi fi\u0219iere cu flag-ul O_DSYNC<\/code>. Dac\u0103 e\u0219ti interesat s\u0103 afli \u00een detaliu ce se \u00eent\u00e2mpl\u0103 cu datele pe parcursul drumului de la codul surs\u0103 la disk, arunc\u0103 o privire pe aceast\u0103<\/a><\/noindex> articol.
\n<\/a><\/noindex><\/p>\n

Particularit\u0103\u021bile folosirii func\u021biei write()<\/h2>\n

\nApelul de sistem write()<\/code> sunt definite \u00een standardul IEEE POSIX<\/a><\/noindex> ca o \u00eencercare de a scrie date \u00een descriptorul de fi\u0219ier. Dup\u0103 finalizarea cu succes a write()<\/code> opera\u021biunii, citirile de date ar trebui s\u0103 returneze exact acei bi\u021bi care au fost anterior scri\u0219i, f\u0103c\u00e2nd acest lucru chiar \u0219i \u00een cazul \u00een care datele sunt accesate din alte procese sau fire (iat\u0103<\/a><\/noindex> sec\u021biunea corespunz\u0103toare din standardul POSIX). Aici<\/a><\/noindex>, \u00een sec\u021biunea dedicat\u0103 interac\u021biunii \u00eentre fire \u0219i opera\u021biile standard cu fi\u0219iere, exist\u0103 o not\u0103 care men\u021bioneaz\u0103 c\u0103, dac\u0103 fiecare dintre cele dou\u0103 fire apeleaz\u0103 aceste func\u021bii, fiecare apel trebuie s\u0103 observe fie toate efectele specificate generate de executarea celuilalt apel, fie s\u0103 nu observe niciun efect. Aceasta permite concluzionarea c\u0103 toate opera\u021biile de intrare\/ie\u0219ire cu fi\u0219iere trebuie s\u0103 blocheze resursa cu care lucreaz\u0103.<\/p>\n

\u00censeamn\u0103 asta c\u0103 opera\u021bia write()<\/code> este atomic\u0103? Din punct de vedere tehnic \u2013 da. Opera\u021biile de citire a datelor trebuie s\u0103 returneze fie tot, fie nimic din ceea ce a fost scris prin write()<\/code>. Dar opera\u021bia write()<\/code>, conform standardului, nu trebuie neap\u0103rat s\u0103 se finalizeze scriind tot ceea ce i-a fost propus s\u0103 scrie. Are voie s\u0103 realizeze scrierea doar a unei p\u0103r\u021bi din date. De exemplu, putem avea dou\u0103 fire, fiecare dintre ele ad\u0103ug\u00e2nd 1024 de octe\u021bi la un fi\u0219ier descris de acela\u0219i descriptor de fi\u0219ier. Din perspectiva standardului, un rezultat acceptabil ar fi ca fiecare dintre opera\u021biile de scriere s\u0103 poat\u0103 ad\u0103uga \u00een fi\u0219ier doar c\u00e2te un octet. Aceste opera\u021bii vor r\u0103m\u00e2ne atomice, dar, dup\u0103 ce se finalizeaz\u0103, datele scrise de ele \u00een fi\u0219ier vor fi amestecate. Iat\u0103<\/a><\/noindex> o discu\u021bie foarte interesant\u0103 pe acest subiect pe Stack Overflow.<\/p>\n

Func\u021biile fsync() \u0219i fdatasync()<\/h2>\n

\nCel mai simplu mod de a trimite datele pe disc este prin apelarea func\u021biei fsync()<\/a><\/noindex>. Aceast\u0103 func\u021bie solicit\u0103 sistemului de operare transferul tuturor blocurilor modificate din cache pe disc. Acesta include \u0219i toate metadatele fi\u0219ierului (timpul de acces, timpul de modificare a fi\u0219ierului etc.). Cred c\u0103 necesitatea acestor metadate apare rar, a\u0219a c\u0103, dac\u0103 \u0219ti\u021bi c\u0103 nu sunt importante pentru dumneavoastr\u0103, pute\u021bi utiliza func\u021bia fdatasync()<\/code>. \u00cen documenta\u021biei<\/a><\/noindex> pe fdatasync()<\/code> se men\u021bioneaz\u0103 c\u0103, \u00een cadrul acestei func\u021bii, se realizeaz\u0103 salvarea pe disc a unui volum de metadate \u201enecesare pentru execu\u021bia corect\u0103 a urm\u0103toarelor opera\u021bii de citire a datelor\u201d. Iar acest lucru este exact ceea ce \u00eengrijoreaz\u0103 cea mai mare parte a aplica\u021biilor.<\/p>\n

O problem\u0103 care poate ap\u0103rea aici este c\u0103 aceste mecanisme nu garanteaz\u0103 c\u0103 fi\u0219ierul va putea fi g\u0103sit dup\u0103 o posibil\u0103 defec\u021biune. \u00cen special, c\u00e2nd se creeaz\u0103 un fi\u0219ier nou, trebuie apelat fsync()<\/code> pentru directorul care \u00eel con\u021bine. Altminteri, dup\u0103 o defectare, se poate \u00eent\u00e2mpla ca acest fi\u0219ier s\u0103 nu existe. Cauza acestui lucru este c\u0103, \u00een UNIX, din cauza utiliz\u0103rii leg\u0103turilor dure, fi\u0219ierul poate exista \u00een mai multe directoare. De aceea, la apel fsync()<\/code> pentru fi\u0219ier nu exist\u0103 nicio modalitate de a \u0219ti care anume director trebuie s\u0103 fie, de asemenea, scris pe disc (aici<\/a><\/noindex> despre acest lucru se poate citi mai \u00een detaliu). Se pare c\u0103 sistemul de fi\u0219iere ext4 este capabil automat<\/a><\/noindex> aplicarea fsync()<\/code> pentru directoarele care con\u021bin fi\u0219ierele corespunz\u0103toare, dar \u00een cazul altor sisteme de fi\u0219iere, acest lucru poate s\u0103 nu fie adev\u0103rat.<\/p>\n

Acest mecanism poate fi implementat diferit \u00een diverse sisteme de fi\u0219iere. Eu am folosit blktrace<\/a><\/noindex> pentru a afla despre ce opera\u021bii de disc sunt utilizate \u00een sistemele de fi\u0219iere ext4 \u0219i XFS. Ambele emit comenzi obi\u0219nuite de scriere pe disc, at\u00e2t pentru con\u021binutul fi\u0219ierelor, c\u00e2t \u0219i pentru jurnalul sistemului de fi\u0219iere, scriu \u00een cache \u0219i finalizeaz\u0103 sarcina, efectu\u00e2nd o scriere FUA (Force Unit Access, scrierea datelor direct pe disc, ocolind cache-ul) \u00een jurnal. Probabil, ele procedeaz\u0103 astfel pentru a confirma desf\u0103\u0219urarea opera\u021biei. Pe discurile care nu suport\u0103 FUA, acest lucru cauzeaz\u0103 dou\u0103 scrieri \u00een cache. Experimentele mele au ar\u0103tat c\u0103 fdatasync()<\/code> este pu\u021bin mai rapid fsync()<\/code>. Utilitar\u0103 blktrace<\/code> indic\u0103 faptul c\u0103 fdatasync()<\/code> de obicei scrie pe disc mai pu\u021bini date (\u00een ext4 fsync()<\/code> scrie 20 KiB, iar fdatasync()<\/code> \u2014 16 KiB). \u00cen plus, am descoperit c\u0103 XFS este pu\u021bin mai rapid dec\u00e2t ext4. \u0218i aici, cu ajutorul blktrace<\/code> am reu\u0219it s\u0103 aflu c\u0103 fdatasync()<\/code> scrie pe disc mai pu\u021bini date (4 KiB \u00een XFS).<\/p>\n

Situa\u021bii neclare care apar \u00een utilizarea fsync()<\/h2>\n

\n\u00cemi pot aminti trei situa\u021bii neclare care se refer\u0103 la fsync()<\/code>, cu care m-am confruntat \u00een practic\u0103.<\/p>\n

Prima astfel de situa\u021bie a avut loc \u00een 2008. Atunci, interfa\u021ba Firefox 3 \u201ese bloca\u201d atunci c\u00e2nd se efectua scrierea pe disc a unui num\u0103r mare de fi\u0219iere. Problema era c\u0103, \u00een implementarea interfe\u021bei pentru stocarea informa\u021biilor despre starea sa, era utilizat\u0103 o baz\u0103 de date SQLite. Dup\u0103 fiecare modificare care avea loc \u00een interfa\u021b\u0103, era apelat\u0103 func\u021bia fsync()<\/code>, ceea ce oferea bune garan\u021bii de stocare durabil\u0103 a datelor. \u00cen sistemul de fi\u0219iere utilizat atunci, ext3, func\u021bia fsync()<\/code> a resetat pe disc toate paginile \u201emurdare\u201d din sistem, nu doar pe cele care aveau leg\u0103tur\u0103 cu fi\u0219ierul respectiv. Aceasta \u00eensemna c\u0103 un clic pe buton \u00een Firefox putea ini\u021bia scrierea de megabytes de date pe discul magnetic, ceea ce putea dura multe secunde. Solu\u021bia problemei, a\u0219a cum am \u00een\u021beles din aceasta<\/a><\/noindex> material, consta \u00een mutarea lucrului cu baza de date \u00een sarcini de fundal asincrone. Aceasta \u00eenseamn\u0103 c\u0103 anterior, \u00een Firefox, au fost implementate cerin\u021be mai stricte pentru fiabilitatea stoc\u0103rii datelor dec\u00e2t era cu adev\u0103rat necesar, iar caracteristicile sistemului de fi\u0219iere ext3 au agravat aceast\u0103 problem\u0103.<\/p>\n

A doua neconcordan\u021b\u0103 a avut loc \u00een 2009. Atunci, dup\u0103 o defec\u021biune a sistemului, utilizatorii noului sistem de fi\u0219iere ext4 s-au confruntat cu faptul c\u0103 multe fi\u0219iere recent create au o lungime zero, \u00een timp ce cu sistemul de fi\u0219iere mai vechi ext3 acest lucru nu s-a \u00eent\u00e2mplat. \u00cen paragraful anterior am men\u021bionat c\u0103 ext3 reseta prea multe date pe disc, ceea ce \u00eencetinea semnificativ func\u021bionarea fsync()<\/code>. Pentru a \u00eembun\u0103t\u0103\u021bi situa\u021bia, \u00een ext4 sunt resetate pe disc doar paginile \u201emurdare\u201d care au leg\u0103tur\u0103 cu un anumit fi\u0219ier. Iar datele altor fi\u0219iere r\u0103m\u00e2n \u00een memorie pentru o perioad\u0103 mult mai lung\u0103 dec\u00e2t \u00een cazul utiliz\u0103rii ext3. Acest lucru a fost realizat pentru a \u00eembun\u0103t\u0103\u021bi performan\u021ba (implicit, datele r\u0103m\u00e2n \u00een aceast\u0103 stare 30 de secunde, iar aceast\u0103 setare poate fi ajustat\u0103 prin dirty_expire_centisecs<\/a><\/noindex>; aici<\/a><\/noindex> , unde se pot g\u0103si materiale suplimentare despre aceasta). Acest lucru \u00eenseamn\u0103 c\u0103 un volum mare de date poate fi pierdut iremediabil dup\u0103 o defec\u021biune. Solu\u021bia acestei probleme const\u0103 \u00een utilizarea fsync()<\/code> \u00een aplica\u021biile care trebuie s\u0103 asigure stocarea fiabil\u0103 a datelor \u0219i s\u0103 le protejeze c\u00e2t mai mult posibil de efectele defec\u021biunilor. Func\u021bia fsync()<\/code> func\u021bioneaz\u0103 mult mai eficient atunci c\u00e2nd se utilizeaz\u0103 ext4 dec\u00e2t atunci c\u00e2nd se utilizeaz\u0103 ext3. Dezavantajul acestei abord\u0103ri este c\u0103 utilizarea sa, ca \u0219i \u00eenainte, \u00eencetine\u0219te executarea anumitor opera\u021biuni, cum ar fi instalarea programelor. Detalii despre aceasta pot fi g\u0103site aici<\/a><\/noindex> \u0219i aici<\/a><\/noindex>.<\/p>\n

A treia problem\u0103, legat\u0103 de fsync()<\/code>, a ap\u0103rut \u00een 2018. Atunci, \u00een cadrul proiectului PostgreSQL, s-a descoperit c\u0103, dac\u0103 func\u021bia fsync()<\/code> se confrunt\u0103 cu o eroare, ea marcheaz\u0103 paginile \u201emurdare\u201d ca fiind \u201ecurate\u201d. Drept rezultat, apelurile urm\u0103toare fsync()<\/code> nu se face nimic cu asemenea pagini. Din acest motiv, paginile modificate sunt stocate \u00een memorie \u0219i nu sunt niciodat\u0103 scrise pe disc. Aceasta este o adev\u0103rat\u0103 catastrof\u0103, deoarece aplica\u021bia va crede c\u0103 anumite date sunt scrise pe disc, c\u00e2nd, de fapt, acestea nu sunt. Astfel de erori fsync()<\/code> apar rar, aplica\u021bia \u00een aceste situa\u021bii aproape c\u0103 nu poate face nimic pentru a lupta \u00eempotriva problemei. \u00cen zilele noastre, c\u00e2nd se \u00eent\u00e2mpl\u0103 acest lucru, PostgreSQL \u0219i alte aplica\u021bii se opresc brusc. Aici<\/a><\/noindex>, \u00een materialul \u201ePot aplica\u021biile s\u0103 recupereze de la erorile fsync?\u201d, aceast\u0103 problem\u0103 este investigat\u0103 \u00een toate detaliile. \u00cen prezent, cea mai bun\u0103 solu\u021bie pentru aceast\u0103 problem\u0103 este utilizarea Direct I\/O cu flagul O_SYNC<\/code> sau cu flagul O_DSYNC<\/code>. Prin aceast\u0103 abordare, sistemul va raporta erorile care pot ap\u0103rea \u00een timpul execut\u0103rii unor opera\u021biuni specifice de scriere a datelor, dar aceast\u0103 abordare necesit\u0103 ca aplica\u021bia s\u0103 gestioneze singur\u0103 bufferele. Detaliile despre aceasta pot fi citite aici<\/a><\/noindex> \u0219i aici<\/a><\/noindex>.<\/p>\n

Deschiderea fi\u0219ierelor folosind flagurile O_SYNC \u0219i O_DSYNC<\/h2>\n

\nS\u0103 revenim la discu\u021bia despre mecanismele Linux care asigur\u0103 stocarea durabil\u0103 a datelor. Anume, este vorba despre utilizarea flagului O_SYNC<\/code> sau flagului O_DSYNC<\/code> la deschiderea fi\u0219ierelor folosind apelul de sistem open()<\/a><\/noindex>. Prin aceast\u0103 abordare, fiecare opera\u021biune de scriere a datelor se efectueaz\u0103 de parc\u0103 dup\u0103 fiecare comand\u0103 write()<\/code> sistemului i se dau, respectiv, comenzi fsync()<\/code> \u0219i fdatasync()<\/code>. \u00cen specifica\u021biilor POSIX<\/a><\/noindex> aceasta se nume\u0219te \u201eFinalizarea integrit\u0103\u021bii fi\u0219ierelor I\/O sincronizate\u201d \u0219i \u201eFinalizarea integrit\u0103\u021bii datelor\u201d. Principalul avantaj al acestei abord\u0103ri este c\u0103 pentru a asigura integritatea datelor trebuie efectuat un singur apel de sistem, nu dou\u0103 (de exemplu \u2014 write()<\/code> \u0219i fdatasync()<\/code>). Principalul dezavantaj al acestei abord\u0103ri este c\u0103 toate opera\u021biunile de scriere care folosesc descriptorul de fi\u0219ier corespunz\u0103tor vor fi sincronizate, ceea ce poate limita oportunit\u0103\u021bile de structurare a codului aplica\u021biei.<\/p>\n

Utilizarea Direct I\/O cu flagul O_DIRECT<\/h2>\n

\nApelul de sistem open()<\/code> sprijin\u0103 flagul O_DIRECT<\/code>, care este destinat s\u0103 efectueze opera\u021biuni de intrare-ie\u0219ire, interac\u021bion\u00e2nd direct cu discul, ocolind cache-ul sistemului de operare. Aceasta, \u00een multe cazuri, \u00eenseamn\u0103 c\u0103 comenzile de scriere emise de program vor fi transmise direct drept comenzi care lucreaz\u0103 cu discul. Dar, \u00een general, acest mecanism nu este un \u00eenlocuitor pentru func\u021biile fsync()<\/code> sau fdatasync()<\/code>. Problema este c\u0103 discul \u00eensu\u0219i poate am\u00e2na sau cache-ul<\/a><\/noindex> comenzile corespunz\u0103toare pentru \u00eenregistrarea datelor. \u0218i, ceea ce este \u0219i mai r\u0103u, \u00een anumite cazuri speciale, opera\u021biile de intrare-ie\u0219ire efectuate cu utilizarea flagului O_DIRECT<\/code>, sunt transmise<\/a><\/noindex> \u00een opera\u021bii tradi\u021bionale cu buffer. Cea mai simpl\u0103 solu\u021bie pentru aceast\u0103 problem\u0103 este s\u0103 folosi\u021bi un flag O_DSYNC<\/code>, ceea ce va \u00eensemna c\u0103 pentru fiecare opera\u021bie de \u00eenregistrare va exista un apel fdatasync()<\/code>.<\/p>\n

Se pare c\u0103 \u00een sistemul de fi\u0219iere XFS a fost recent ad\u0103ugat un \u201edrum rapid\u201d pentru O_DIRECT|O_DSYNC<\/code>-\u00eenregistrarea datelor. Dac\u0103 se suprascrie un bloc utiliz\u00e2nd O_DIRECT|O_DSYNC<\/code>, atunci XFS, \u00een loc s\u0103 cur\u0103\u021be cache-ul, va efectua comanda de \u00eenregistrare FUA, \u00een cazul \u00een care dispozitivul o suport\u0103. M-am convins de acest lucru folosind utilitarul blktrace<\/code> \u00een sistemul Linux 5.4\/Ubuntu 20.04. Aceast\u0103 abordare ar trebui s\u0103 fie mai eficient\u0103, deoarece folose\u0219te o cantitate minim\u0103 de date scris\u0103 pe disc \u0219i aplic\u0103 o singur\u0103 opera\u021bie, nu dou\u0103 (\u00eenregistrare \u0219i cur\u0103\u021bare cache). Am g\u0103sit un link la patch<\/a><\/noindex> nucleul anului 2018, \u00een care este implementat acest mecanism. Exist\u0103 o discu\u021bie despre aplicarea acestei optimiz\u0103ri \u0219i \u00een alte sisteme de fi\u0219iere, dar, din c\u00e2te \u0219tiu eu, XFS este singurul sistem de fi\u0219iere care suport\u0103 asta p\u00e2n\u0103 acum.<\/p>\n

Func\u021bia sync_file_range()<\/h2>\n

\n\u00cen Linux exist\u0103 un apel de sistem sync_file_range()<\/a><\/noindex>, care permite cur\u0103\u021barea pe disc doar a unei p\u0103r\u021bi din fi\u0219ier, nu a \u00eentregului fi\u0219ier. Acest apel ini\u021biaz\u0103 o cur\u0103\u021bare asynchronic\u0103 a datelor \u0219i nu a\u0219teapt\u0103 finalizarea acesteia. Dar \u00een documenta\u021bia sync_file_range()<\/code> se spune c\u0103 aceast\u0103 comand\u0103 este \u201efoarte periculoas\u0103\u201d. Nu este recomandat s\u0103 fie folosit\u0103. Caracteristicile \u0219i pericolele sync_file_range()<\/code> sunt foarte bine descrise \u00een aceasta<\/a><\/noindex> material. \u00cen special, se pare c\u0103 acest apel folose\u0219te RocksDB pentru a gestiona momentul \u00een care nucleul cur\u0103\u021b\u0103 datele \u201emurdare\u201d pe disc. Dar, \u00een acela\u0219i timp, din nou, pentru a asigura stocarea robust\u0103 a datelor, se folose\u0219te \u0219i fdatasync()<\/code>. \u00cen cod<\/a><\/noindex> RocksDB are comentarii interesante pe aceast\u0103 tem\u0103. De exemplu, se pare c\u0103 apelul sync_file_range()<\/code> atunci c\u00e2nd este utilizat cu ZFS nu duce la cur\u0103\u021barea datelor pe disc. Experien\u021ba \u00eemi spune c\u0103 codul care este folosit rar, poate con\u021bine erori. De aceea, a\u0219 recomanda s\u0103 nu se foloseasc\u0103 acest apel de sistem f\u0103r\u0103 necesitate extrem\u0103.<\/p>\n

Apelurile de sistem care ajut\u0103 la asigurarea stoc\u0103rii robuste a datelor<\/h2>\n

\nAm ajuns la concluzia c\u0103 pentru efectuarea opera\u021biunilor de intrare\/ie\u0219ire care asigur\u0103 stocarea persistent\u0103 a datelor, se pot folosi trei abord\u0103ri. Toate necesit\u0103 apelarea func\u021biei fsync()<\/code> pentru directorul \u00een care a fost creat fi\u0219ierul. Iat\u0103 aceste abord\u0103ri:<\/p>\n

    \n
  1. Apelarea func\u021biei fdatasync()<\/code> sau fsync()<\/code> dup\u0103 func\u021bie write()<\/code> (este recomandat s\u0103 folosi\u021bi fdatasync()<\/code>).<\/li>\n
  2. Lucrul cu un descriptor de fi\u0219ier deschis cu firul O_DSYNC<\/code> sau O_SYNC<\/code> (este recomandat \u2013 cu firul O_DSYNC<\/code>).<\/li>\n
  3. Utilizarea comenzii pwritev2()<\/code> cu flag-ul RWF_DSYNC<\/code> sau RWF_SYNC<\/code> (preferabil \u2013 cu firul RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Note despre performan\u021b\u0103<\/h2>\n

    \nNu m-am ocupat de m\u0103surarea detaliat\u0103 a performan\u021bei diverselor mecanisme investigate de mine. Diferen\u021bele observate \u00een viteza lor de operare sunt destul de mici. Acest lucru \u00eenseamn\u0103 c\u0103 a\u0219 putea gre\u0219i, iar \u00een alte condi\u021bii acela\u0219i lucru poate ar\u0103ta alte rezultate. Mai \u00eent\u00e2i voi vorbi despre ceea ce influen\u021beaz\u0103 mai mult performan\u021ba, apoi despre ceea ce influen\u021beaz\u0103 mai pu\u021bin performan\u021ba.<\/p>\n

      \n
    1. Rescrierea datelor din fi\u0219ier este mai rapid\u0103 dec\u00e2t ad\u0103ugarea de date la fi\u0219ier (c\u00e2\u0219tigul de performan\u021b\u0103 poate varia \u00eentre 2-100%). Ad\u0103ugarea de date la fi\u0219ier necesit\u00e2nd modific\u0103ri suplimentare \u00een metadatele fi\u0219ierului, chiar \u0219i dup\u0103 apelul de sistem fallocate()<\/code>, dar amploarea acestui efect poate varia. Recomand, pentru a asigura cea mai bun\u0103 performan\u021b\u0103, s\u0103 apela\u021bi fallocate()<\/code> pentru alocarea anticipat\u0103 a spa\u021biului necesar. Apoi, acest spa\u021biu trebuie umplut explicit cu zerouri \u0219i apelat fsync()<\/code>. Datorit\u0103 acestui lucru, blocurile corespunz\u0103toare din sistemul de fi\u0219iere vor fi etichetate ca \u201ealocate\u201d, \u0219i nu ca \u201enealocate\u201d. Aceasta ofer\u0103 o mic\u0103 (aproximativ 2%) \u00eembun\u0103t\u0103\u021bire a performan\u021bei. \u00cen plus, la unele discuri, prima opera\u021biune de acces la un bloc poate fi mai lent\u0103 dec\u00e2t altele. Aceasta \u00eenseamn\u0103 c\u0103 umplerea spa\u021biului cu zerouri poate duce la o \u00eembun\u0103t\u0103\u021bire semnificativ\u0103 (aproximativ 100%) a performan\u021bei. \u00cen special, acest lucru poate ap\u0103rea cu discurile AWS EBS<\/a><\/noindex> (acestea sunt date neoficiale, nu am reu\u0219it s\u0103 le confirm). Acela\u0219i lucru se aplic\u0103 \u0219i stoc\u0103rilor GCP Persistent Disk<\/a><\/noindex> (\u0219i aceasta este deja o informa\u021bie oficial\u0103, confirmat\u0103 prin teste). Al\u021bi speciali\u0219ti au f\u0103cut observa\u021bii similare , referitoare la diverse discuri.<\/a><\/noindex>Cu c\u00e2t sunt mai pu\u021bine apeluri de sistem - cu at\u00e2t mai mare este performan\u021ba (c\u00e2\u0219tigul poate fi de aproximativ 5%). Se pare c\u0103 apelul<\/li>\n
    2. sau apelul open()<\/code> cu flag-ul O_DSYNC<\/code> este mai rapid dec\u00e2t apelul pwritev2()<\/code> cu flag-ul RWF_SYNC<\/code> mai rapid dec\u00e2t apelul fdatasync()<\/code>Suspectez c\u0103 aceasta este legat\u0103 de faptul c\u0103, prin aceast\u0103 abordare, rolul \u00eel joac\u0103 faptul c\u0103 pentru a rezolva aceea\u0219i problem\u0103 este nevoie de mai pu\u021bine apeluri de sistem (o singur\u0103 apelare \u00een loc de dou\u0103). Dar diferen\u021ba de performan\u021b\u0103 este foarte mic\u0103, a\u0219a c\u0103 pute\u021bi s\u0103 nu \u00eei acorda\u021bi aten\u021bie \u0219i s\u0103 folosi\u021bi \u00een aplica\u021bie ceea ce nu va duce la complicarea logicii acesteia.<\/li>\n<\/ol>\n

      \nDac\u0103 sunte\u021bi interesat de tema stoc\u0103rii durabile a datelor, iat\u0103 c\u00e2teva materiale utile:<\/p>\n