{"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\/sk\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Trval\u00e9 ukladanie d\u00e1t a s\u00faborov\u00e9 API Linuxu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pri sk\u00faman\u00ed odolnosti ukladania d\u00e1t v cloudov\u00fdch syst\u00e9moch som sa rozhodol preveri\u0165 svoje vedomosti a uisti\u0165 sa, \u017ee rozumiem z\u00e1kladn\u00fdm veciam. Ja som za\u010dal \u010d\u00edtan\u00edm \u0161pecifik\u00e1cie NVMe<\/a><\/noindex> aby som porozumel z\u00e1ruk\u00e1m t\u00fdkaj\u00facim sa odoln\u00e9ho ukladania d\u00e1t (teda z\u00e1ruk\u00e1m, \u017ee d\u00e1ta bud\u00fa dostupn\u00e9 po zlyhan\u00ed syst\u00e9mu), ktor\u00e9 n\u00e1m poskytuj\u00fa disky NVMe. Urobil som nasleduj\u00face z\u00e1kladn\u00e9 zistenia: d\u00e1ta sa musia pova\u017eova\u0165 za po\u0161koden\u00e9 od okamihu vydania pr\u00edkazu na z\u00e1pis d\u00e1t a\u017e do momentu, ke\u010f sa dokon\u010d\u00ed ich z\u00e1pis na m\u00e9dium. Av\u0161ak vo v\u00e4\u010d\u0161ine programov na z\u00e1pis d\u00e1t sa bez probl\u00e9mov pou\u017e\u00edvaj\u00fa syst\u00e9mov\u00e9 volania.<\/p>\n

V tomto materi\u00e1li sk\u00famam mechanizmy odoln\u00e9ho ukladania d\u00e1t, ktor\u00e9 poskytuj\u00fa s\u00faborov\u00e9 API Linuxu. Zd\u00e1 sa, \u017ee by to malo by\u0165 jednoduch\u00e9: program vol\u00e1 pr\u00edkaz write()<\/code>, a po dokon\u010den\u00ed tejto oper\u00e1cie bud\u00fa d\u00e1ta spo\u013eahlivo ulo\u017een\u00e9 na disku. Ale write()<\/code> iba kop\u00edruje d\u00e1ta aplik\u00e1cie do vyrovn\u00e1vacej pam\u00e4te jadra, ktor\u00e1 sa nach\u00e1dza v opera\u010dnej pam\u00e4ti. Aby sa syst\u00e9m prin\u00fatil zapisova\u0165 d\u00e1ta na disk, je potrebn\u00e9 pou\u017ei\u0165 niektor\u00e9 \u010fal\u0161ie mechanizmy.<\/p>\n

\"Trval\u00e9<\/a><\/noindex><\/p>\n

Celkovo tento materi\u00e1l predstavuje s\u00fabor pozn\u00e1mok o tom, \u010do som sa nau\u010dil k t\u00e9me, ktor\u00e1 ma zauj\u00edma. Ak by som mal ve\u013emi stru\u010dne zhrn\u00fa\u0165 to najd\u00f4le\u017eitej\u0161ie, tak vych\u00e1dza, \u017ee na organiz\u00e1ciu odoln\u00e9ho ukladania d\u00e1t je potrebn\u00e9 pou\u017e\u00edva\u0165 pr\u00edkaz fdatasync()<\/code> alebo otvori\u0165 s\u00fabory s pr flagom O_DSYNC<\/code>. Ak v\u00e1s zauj\u00edma podrobne, \u010do sa deje s d\u00e1tami na ceste od programov\u00e9ho k\u00f3du k disku, pozrite sa na t\u00fato<\/a><\/noindex> \u010dl\u00e1nok.
\n<\/a><\/noindex><\/p>\n

Vlastnosti pou\u017e\u00edvania funkcie write()<\/h2>\n

\nSyst\u00e9mov\u00e9 volanie write()<\/code> je definovan\u00e9 v \u0161tandarde IEEE POSIX<\/a><\/noindex> ako pokus o z\u00e1pis d\u00e1t do s\u00faborov\u00e9ho deskriptora. Po \u00faspe\u0161nom dokon\u010den\u00ed, write()<\/code> oper\u00e1cie \u010d\u00edtania d\u00e1t by mali vraca\u0165 presne tie bajty, ktor\u00e9 boli predt\u00fdm zap\u00edsan\u00e9, a to aj v pr\u00edpade, \u017ee s\u00fa k d\u00e1tam pristupovan\u00e9 z in\u00fdch procesov alebo vl\u00e1kien (tu<\/a><\/noindex> pr\u00edslu\u0161n\u00e1 \u010das\u0165 \u0161tandardu POSIX). Tu<\/a><\/noindex>, v sekcii t\u00fdkaj\u00facej sa interakcie tokov s be\u017en\u00fdmi s\u00faborov\u00fdmi oper\u00e1ciami sa nach\u00e1dza pozn\u00e1mka, ktor\u00e1 uv\u00e1dza, \u017ee ak ka\u017ed\u00fd z dvoch tokov vol\u00e1 tieto funkcie, ka\u017ed\u00fd volanie mus\u00ed vidie\u0165 bu\u010f v\u0161etky ozna\u010den\u00e9 n\u00e1sledky, ku ktor\u00fdm vedie vykon\u00e1vanie in\u00e9ho volania, alebo nevidie\u0165 v\u00f4bec \u017eiadne n\u00e1sledky. To umo\u017e\u0148uje usudzova\u0165, \u017ee v\u0161etky oper\u00e1cie vstupu\/v\u00fdstupu s\u00faborov musia udr\u017eiava\u0165 z\u00e1mok na zdroji, s ktor\u00fdm pracuj\u00fa.<\/p>\n

Znamen\u00e1 to, \u017ee oper\u00e1cia write()<\/code> je at\u00f3mov\u00e1? Technicky \u00e1no. Oper\u00e1cie \u010d\u00edtania d\u00e1t by mali vr\u00e1ti\u0165 bu\u010f v\u0161etko, alebo ni\u010d z toho, \u010do bolo zap\u00edsan\u00e9 pomocou write()<\/code>. No oper\u00e1cia write()<\/code>, pod\u013ea \u0161tandardu, nemus\u00ed nevyhnutne skon\u010di\u0165 z\u00e1pisom v\u0161etk\u00e9ho, \u010do jej bolo navrhnut\u00e9 zap\u00edsa\u0165. Jej je dovolen\u00e9 zap\u00edsa\u0165 len \u010das\u0165 \u00fadajov. Napr\u00edklad m\u00f4\u017eeme ma\u0165 dva toky, z ktor\u00fdch ka\u017ed\u00fd prid\u00e1va 1024 bajtov do s\u00faboru opisovan\u00e9ho rovnak\u00fdm s\u00faborov\u00fdm deskriptorom. Z h\u013eadiska \u0161tandardu bude prijate\u013en\u00fdm v\u00fdsledkom, ak ka\u017ed\u00e1 z oper\u00e1ci\u00ed z\u00e1pisu bude m\u00f4c\u0165 prida\u0165 k s\u00faboru iba jeden bajt. Tieto oper\u00e1cie zostan\u00fa at\u00f3mov\u00e9, ale po ich dokon\u010den\u00ed bud\u00fa \u00fadaje, ktor\u00e9 zap\u00edsali do s\u00faboru, zmie\u0161an\u00e9. Tu s\u00fa<\/a><\/noindex> ve\u013emi zauj\u00edmav\u00e1 diskusia na t\u00fato t\u00e9mu na Stack Overflow.<\/p>\n

Funkcie fsync() a fdatasync()<\/h2>\n

\nNajjednoduch\u0161\u00ed sp\u00f4sob, ako prenies\u0165 d\u00e1ta na disk, spo\u010d\u00edva vo volan\u00ed funkcie fsync()<\/a><\/noindex>. T\u00e1to funkcia \u017eiada opera\u010dn\u00fd syst\u00e9m, aby preniesol v\u0161etky modifikovan\u00e9 bloky z cache na disk. Sem patr\u00ed aj v\u0161etka metadata s\u00faboru (\u010das pr\u00edstupu, \u010das modifik\u00e1cie s\u00faboru a tak \u010falej). Domnievam sa, \u017ee potreba t\u00fdchto m\u00e9tad\u00e1t nast\u00e1va zriedka, tak\u017ee ak viete, \u017ee pre v\u00e1s nie s\u00fa d\u00f4le\u017eit\u00e9, m\u00f4\u017eete pou\u017e\u00edva\u0165 funkciu fdatasync()<\/code>. V pomoc<\/a><\/noindex> o fdatasync()<\/code> sa uv\u00e1dza, \u017ee po\u010das pr\u00e1ce tejto funkcie sa vykon\u00e1va prenos na disk tak\u00e9ho objemu m\u00e9tad\u00e1t, ktor\u00fd \"je potrebn\u00fd na spr\u00e1vne vykonanie nasleduj\u00facich oper\u00e1ci\u00ed \u010d\u00edtania \u00fadajov\". A to je presne to, \u010do tr\u00e1pi v\u00e4\u010d\u0161inu aplik\u00e1ci\u00ed.<\/p>\n

Jedn\u00fdm z probl\u00e9mov, ktor\u00e9 sa tu m\u00f4\u017eu vyskytn\u00fa\u0165, je, \u017ee tieto mechanizmy nezaru\u010duj\u00fa, \u017ee s\u00fabor bude mo\u017en\u00e9 po mo\u017enej poruche znovu n\u00e1js\u0165. Najm\u00e4 pri vytv\u00e1ran\u00ed nov\u00e9ho s\u00faboru je potrebn\u00e9 zavola\u0165 fsync()<\/code> pre adres\u00e1r, ktor\u00fd ho obsahuje. Inak sa po zlyhan\u00ed m\u00f4\u017ee sta\u0165, \u017ee tento s\u00fabor neexistuje. D\u00f4vodom je, \u017ee v UNIXe, kv\u00f4li pou\u017eitiu tvrd\u00fdch odkazov, m\u00f4\u017ee s\u00fabor existova\u0165 v nieko\u013ek\u00fdch adres\u00e1roch. Preto pri vyvolan\u00ed fsync()<\/code> pre s\u00fabor neexistuje sp\u00f4sob, ako zisti\u0165, ktor\u00e9 \u00fadaje konkr\u00e9tneho adres\u00e1ra je tie\u017e potrebn\u00e9 zap\u00edsa\u0165 na disk (tu<\/a><\/noindex> o tomto sa d\u00e1 pre\u010d\u00edta\u0165 podrobnej\u0161ie). Vyzer\u00e1 to, \u017ee s\u00faborov\u00fd syst\u00e9m ext4 je schopn\u00fd automaticky<\/a><\/noindex> pou\u017e\u00edva\u0165 fsync()<\/code> na adres\u00e1re, ktor\u00e9 obsahuj\u00fa pr\u00edslu\u0161n\u00e9 s\u00fabory, ale v pr\u00edpade in\u00fdch s\u00faborov\u00fdch syst\u00e9mov to nemus\u00ed by\u0165 tak.<\/p>\n

Tento mechanizmus m\u00f4\u017ee by\u0165 r\u00f4zne implementovan\u00fd v r\u00f4znych s\u00faborov\u00fdch syst\u00e9moch. Pou\u017e\u00edval som blktrace<\/a><\/noindex> na to, aby som zistil, ak\u00e9 diskov\u00e9 oper\u00e1cie sa pou\u017e\u00edvaj\u00fa v s\u00faborov\u00fdch syst\u00e9moch ext4 a XFS. Obe generuj\u00fa be\u017en\u00e9 pr\u00edkazy na z\u00e1pis na disk a pre obsah s\u00faborov, aj pre \u017eurn\u00e1l s\u00faborov\u00e9ho syst\u00e9mu, uvo\u013e\u0148uj\u00fa cache a kon\u010dia pr\u00e1ci vykon\u00e1vaj\u00fac FUA-z\u00e1pis (Force Unit Access, z\u00e1pis \u00fadajov priamo na disk, obch\u00e1dzaj\u00fac cache) do \u017eurn\u00e1lu. Pravdepodobne to robia pr\u00e1ve tak, aby potvrdili fakt uskuto\u010dnenia oper\u00e1cie. Na diskoch, ktor\u00e9 nepodporuj\u00fa FUA, to vy\u017eaduje dva z\u00e1pisy cache. Moje experimenty uk\u00e1zali, \u017ee fdatasync()<\/code> trochu r\u00fdchlej\u0161ie fsync()<\/code>. N\u00e1stroj blktrace<\/code> nazna\u010duje, \u017ee fdatasync()<\/code> zvy\u010dajne p\u00ed\u0161e na disk menej \u00fadajov (v ext4 fsync()<\/code> zapisuje 20 KiB, a fdatasync()<\/code> \u2014 16 KiB). Okrem toho som zistil, \u017ee XFS je trochu r\u00fdchlej\u0161\u00ed ako ext4. A tu pomocou blktrace<\/code> sa mi podarilo zisti\u0165, \u017ee fdatasync()<\/code> zapisuje na disk menej \u00fadajov (4 KiB v XFS).<\/p>\n

Nejednozna\u010dn\u00e9 situ\u00e1cie, ktor\u00e9 vznikaj\u00fa pri pou\u017e\u00edvan\u00ed fsync()<\/h2>\n

\nM\u00f4\u017eem si spomen\u00fa\u0165 na tri nejednozna\u010dn\u00e9 situ\u00e1cie, ktor\u00e9 sa t\u00fdkaj\u00fa fsync()<\/code>, s ktor\u00fdmi som sa stretol v praxi.<\/p>\n

Prv\u00fd tak\u00fd pr\u00edpad sa stal v roku 2008. Vtedy rozhranie Firefox 3 \u201ezasek\u00e1valo\u201c, ak sa vykon\u00e1val z\u00e1pis na disk ve\u013ek\u00e9ho mno\u017estva s\u00faborov. Probl\u00e9m spo\u010d\u00edval v tom, \u017ee v implement\u00e1cii rozhrania na ulo\u017eenie inform\u00e1ci\u00ed o jeho stave bola pou\u017eit\u00e1 datab\u00e1za SQLite. Po ka\u017edej zmene, ktor\u00e1 nastala v rozhran\u00ed, sa volala funkcia fsync()<\/code>, \u010do poskytovalo dobr\u00e9 z\u00e1ruky trval\u00e9ho uchov\u00e1vania \u00fadajov. Vtedy pou\u017e\u00edvan\u00fd s\u00faborov\u00fd syst\u00e9m ext3 funkciu fsync()<\/code> vymaz\u00e1valo na disk v\u0161etky \u201e\u0161pinav\u00e9\u201c str\u00e1nky v syst\u00e9me, nielen tie, ktor\u00e9 mali s\u00favislos\u0165 s pr\u00edslu\u0161n\u00fdm s\u00faborom. To znamenalo, \u017ee kliknutie na tla\u010didlo vo Firefoxe mohlo spusti\u0165 z\u00e1pis megabajtov \u00fadajov na magnetick\u00fd disk, \u010do mohlo trva\u0165 dlh\u00e9 sekundy. Rie\u0161enie probl\u00e9mu, ako som pochopil z tohto<\/a><\/noindex> materi\u00e1lu, spo\u010d\u00edvalo v presunut\u00ed pr\u00e1ce s datab\u00e1zou do asynchr\u00f3nnych pozadov\u00fdch \u00faloh. To znamen\u00e1, \u017ee sk\u00f4r vo Firefoxe boli zaveden\u00e9 pr\u00edsnej\u0161ie po\u017eiadavky na stabilitu ukladania \u00fadajov, ne\u017e by bolo naozaj potrebn\u00e9, a \u0161pecifik\u00e1 s\u00faborov\u00e9ho syst\u00e9mu ext3 t\u00fato probl\u00e9m len zhor\u0161ili.<\/p>\n

Druh\u00e1 nezrovnalos\u0165 sa stala v roku 2009. Vtedy, po zlyhan\u00ed syst\u00e9mu, pou\u017e\u00edvatelia novej s\u00faborovej s\u00fastavy ext4 narazili na probl\u00e9m, \u017ee mnoh\u00e9 ned\u00e1vno vytvoren\u00e9 s\u00fabory maj\u00fa nulov\u00fa d\u013a\u017eku, zatia\u013e \u010do pri star\u0161ej s\u00faborovej s\u00fastave ext3 sa to nestalo. V predch\u00e1dzaj\u00facom odseku som hovoril o tom, \u017ee ext3 zaznamen\u00e1vala na disk pr\u00edli\u0161 ve\u013ea \u00fadajov, \u010do v\u00fdrazne spoma\u013eovalo pr\u00e1cu fsync()<\/code>. Aby sa situ\u00e1cia zlep\u0161ila, v ext4 sa na disk zaznamen\u00e1vaj\u00fa iba tie \u201e\u0161pinav\u00e9\u201c str\u00e1nky, ktor\u00e9 sa t\u00fdkaj\u00fa konkr\u00e9tneho s\u00faboru. A \u00fadaje in\u00fdch s\u00faborov zost\u00e1vaj\u00fa v pam\u00e4ti ove\u013ea dlh\u0161ie, ne\u017e pri pou\u017eit\u00ed ext3. Tieto zmeny boli vykonan\u00e9 na zlep\u0161enie v\u00fdkonu (\u00fadajne \u00fadaje zost\u00e1vaj\u00fa v tomto stave 30 sek\u00fand, nastavenia mo\u017en\u00e9 s pomocou dirty_expire_centisecs<\/a><\/noindex>; tu<\/a><\/noindex> n\u00e1jdete \u010fal\u0161ie materi\u00e1ly o tom). To znamen\u00e1, \u017ee ve\u013ek\u00e9 mno\u017estvo \u00fadajov m\u00f4\u017ee by\u0165 nezvratne straten\u00e9 po zlyhan\u00ed. Rie\u0161en\u00edm tohto probl\u00e9mu je pou\u017e\u00edvanie fsync()<\/code> v aplik\u00e1ci\u00e1ch, ktor\u00e9 musia zabezpe\u010di\u0165 st\u00e1los\u0165 ukladania \u00fadajov a maxim\u00e1lne ich ochr\u00e1ni\u0165 pred n\u00e1sledkami zlyhan\u00ed. Funkcia fsync()<\/code> pracuje pri pou\u017eit\u00ed ext4 ove\u013ea efekt\u00edvnej\u0161ie ne\u017e pri pou\u017eit\u00ed ext3. Nev\u00fdhodou tohto pr\u00edstupu je, \u017ee jeho pou\u017eitie, ako aj predt\u00fdm, spoma\u013euje vykon\u00e1vanie niektor\u00fdch oper\u00e1ci\u00ed, ako je in\u0161tal\u00e1cia programov. Podrobnosti o tom pozrite tu<\/a><\/noindex> a tu<\/a><\/noindex>.<\/p>\n

Tret\u00ed probl\u00e9m, ktor\u00fd sa t\u00fdka fsync()<\/code>, sa objavil v roku 2018. Vtedy, v r\u00e1mci projektu PostgreSQL, sa zistilo, \u017ee ak funkcia fsync()<\/code> naraz\u00ed na chybu, ozna\u010duje \u201e\u0161pinav\u00e9\u201c str\u00e1nky ako \u201e\u010dist\u00e9\u201c. V d\u00f4sledku toho nasleduj\u00face volania fsync()<\/code> s tak\u00fdmito str\u00e1nkami sa ni\u010d nerob\u00ed. Kv\u00f4li tomu sa upraven\u00e9 str\u00e1nky uchov\u00e1vaj\u00fa v pam\u00e4ti a nikdy sa nezapisuj\u00fa na disk. To je naozaj katastrofa, preto\u017ee aplik\u00e1cia si bude myslie\u0165, \u017ee nejak\u00e9 \u00fadaje s\u00fa zap\u00edsan\u00e9 na disku, ale v skuto\u010dnosti to tak nie je. Tak\u00e9to zlyhania fsync()<\/code> sa zriedkavo vyskytuj\u00fa, aplik\u00e1cia v tak\u00fdch situ\u00e1ci\u00e1ch takmer ni\u010d nem\u00f4\u017ee urobi\u0165 na obranu pred probl\u00e9mom. V s\u00fa\u010dasnosti, ke\u010f sa to stane, PostgreSQL a ostatn\u00e9 aplik\u00e1cie havarijne ukon\u010dia \u010dinnos\u0165. Tu<\/a><\/noindex>, v materi\u00e1li \u201eM\u00f4\u017eu aplik\u00e1cie obnovi\u0165 zlyhania fsync?\u201c, je tento probl\u00e9m presk\u00faman\u00fd vo v\u0161etk\u00fdch podrobnostiach. V s\u00fa\u010dasnosti je najlep\u0161\u00edm rie\u0161en\u00edm tohto probl\u00e9mu pou\u017eitie Direct I\/O s pr\u00edznakom O_SYNC<\/code> alebo s pr\u00edznakom O_DSYNC<\/code>. Pri takomto pr\u00edstupe syst\u00e9m ozn\u00e1mi chyby, ktor\u00e9 sa m\u00f4\u017eu vyskytn\u00fa\u0165 pri vykon\u00e1van\u00ed konkr\u00e9tnych oper\u00e1ci\u00ed z\u00e1pisu \u00fadajov, ale tento pr\u00edstup vy\u017eaduje, aby aplik\u00e1cia spravovala vyrovn\u00e1vacie pam\u00e4te sama. Podrobnosti o tomto si pre\u010d\u00edtajte tu<\/a><\/noindex> a tu<\/a><\/noindex>.<\/p>\n

Otv\u00e1ranie s\u00faborov pomocou pr\u00edznakov O_SYNC a O_DSYNC<\/h2>\n

\nVr\u00e1\u0165me sa k diskusii o mechanizmoch Linuxu, ktor\u00e9 zabezpe\u010duj\u00fa trval\u00e9 ukladanie d\u00e1t. Konkr\u00e9tne ide o pou\u017eitie pr\u00edznaku O_SYNC<\/code> alebo pr\u00edznaku O_DSYNC<\/code> pri otv\u00e1ran\u00ed s\u00faborov pomocou syst\u00e9mov\u00e9ho volania open()<\/a><\/noindex>. Pri takomto pr\u00edstupe sa ka\u017ed\u00e1 oper\u00e1cia z\u00e1pisu \u00fadajov vykon\u00e1va tak, akoby po ka\u017edej miere write()<\/code> syst\u00e9mu sa d\u00e1vaj\u00fa, pr\u00edpadne pr\u00edkazy fsync()<\/code> a fdatasync()<\/code>. V \u0161pecifik\u00e1cie POSIX<\/a><\/noindex> to sa naz\u00fdva \u201eSynchronized I\/O File Integrity Completion\u201c a \u201eData Integrity Completion\u201c. Hlavnou v\u00fdhodou tohto pr\u00edstupu je, \u017ee na zabezpe\u010denie integrity d\u00e1t je potrebn\u00e9 vykona\u0165 iba jeden syst\u00e9mov\u00fd pr\u00edkaz, nie dva (napr\u00edklad \u2014 write()<\/code> a fdatasync()<\/code>). Hlavnou nev\u00fdhodou tohto pr\u00edstupu je, \u017ee v\u0161etky oper\u00e1cie z\u00e1pisu, ktor\u00e9 pou\u017e\u00edvaj\u00fa pr\u00edslu\u0161n\u00fd s\u00faborov\u00fd deskriptor, bud\u00fa synchronizovan\u00e9, \u010do m\u00f4\u017ee obmedzi\u0165 mo\u017enosti \u0161trukt\u00farovania k\u00f3du aplik\u00e1cie.<\/p>\n

Pou\u017eitie Direct I\/O s pr\u00edznakom O_DIRECT<\/h2>\n

\nSyst\u00e9mov\u00e9 volanie open()<\/code> podporuje pr\u00edznak O_DIRECT<\/code>, ktor\u00fd je ur\u010den\u00fd na to, aby sa, obch\u00e1dzaj\u00fac vyrovn\u00e1vaciu pam\u00e4\u0165 opera\u010dn\u00e9ho syst\u00e9mu, vykon\u00e1vali oper\u00e1cie vstupu-v\u00fdstupu priamo s diskom. To vo v\u00e4\u010d\u0161ine pr\u00edpadov znamen\u00e1, \u017ee pr\u00edkazy z\u00e1pisu, ktor\u00e9 vyd\u00e1va program, bud\u00fa priamo prekladan\u00e9 do pr\u00edkazov zameran\u00fdch na pr\u00e1cu s diskom. Ale vo v\u0161eobecnosti tento mechanizmus nie je n\u00e1hradou funkci\u00ed fsync()<\/code> alebo fdatasync()<\/code>. Faktom je, \u017ee samotn\u00fd disk m\u00f4\u017ee odlo\u017ei\u0165 alebo cacheova\u0165<\/a><\/noindex> prisl\u00fachaj\u00face pr\u00edkazy na z\u00e1pis d\u00e1t. A \u010do je e\u0161te hor\u0161ie, v niektor\u00fdch \u0161peci\u00e1lnych pr\u00edpadoch oper\u00e1cie vstupu a v\u00fdstupu vykon\u00e1van\u00e9 s pou\u017eit\u00edm pr\u00edznaku O_DIRECT<\/code>, s\u00fa pren\u00e1\u0161an\u00e9<\/a><\/noindex> na tradi\u010dn\u00e9 buffered oper\u00e1cie. Najjednoduch\u0161\u00ed sp\u00f4sob, ako t\u00fato situ\u00e1ciu vyrie\u0161i\u0165, je pou\u017ei\u0165 na otvorenie s\u00faborov aj pr\u00edznak O_DSYNC<\/code>, \u010do bude znamena\u0165, \u017ee ka\u017ed\u00e1 oper\u00e1cia z\u00e1pisu bude nasledovan\u00e1 volan\u00edm fdatasync()<\/code>.<\/p>\n

Uk\u00e1zalo sa, \u017ee v s\u00faborovom syst\u00e9me XFS bol ned\u00e1vno pridan\u00fd \"r\u00fdchly sp\u00f4sob\" pre O_DIRECT|O_DSYNC<\/code>-z\u00e1pis d\u00e1t. Ak sa prepisuje blok s pou\u017eit\u00edm O_DIRECT|O_DSYNC<\/code>, XFS, namiesto vypr\u00e1zdnenia cache, vykon\u00e1 pr\u00edkaz FUA-z\u00e1pisu, ak to zariadenie podporuje. Potvrdil som to pomocou n\u00e1stroja blktrace<\/code> v syst\u00e9me Linux 5.4\/Ubuntu 20.04. Tento pr\u00edstup by mal by\u0165 efekt\u00edvnej\u0161\u00ed, preto\u017ee jeho pou\u017eit\u00edm sa na disk zapisuje minim\u00e1lne mno\u017estvo \u00fadajov a z\u00e1rove\u0148 sa vykon\u00e1va jedna oper\u00e1cia, a nie dve (z\u00e1pis a vypr\u00e1zdnenie cache). Na\u0161iel som odkaz na z\u00e1plata<\/a><\/noindex> jadro z roku 2018, v ktorom je tento mechanizmus implementovan\u00fd. Tam je aj diskusia o aplik\u00e1cii tejto optimaliz\u00e1cie aj v in\u00fdch s\u00faborov\u00fdch syst\u00e9moch, ale pokia\u013e viem, XFS je zatia\u013e jedin\u00fd s\u00faborov\u00fd syst\u00e9m, ktor\u00fd to podporuje.<\/p>\n

Funkcia sync_file_range()<\/h2>\n

\nV Linuxe existuje syst\u00e9mov\u00fd volanie sync_file_range()<\/a><\/noindex>, ktor\u00e9 umo\u017e\u0148uje vypr\u00e1zdni\u0165 na disk iba \u010das\u0165 s\u00faboru, a nie cel\u00fd s\u00fabor. Toto volanie iniciuje asynchr\u00f3nne vypr\u00e1zdnenie d\u00e1t a ne\u010dak\u00e1 na jeho dokon\u010denie. Ale v dokument\u00e1cii k sync_file_range()<\/code> sa uv\u00e1dza, \u017ee tento pr\u00edkaz \"je ve\u013emi nebezpe\u010dn\u00fd\". Odpor\u00fa\u010da sa n\u00edm neprera\u010fova\u0165. \u0160pecifik\u00e1 a nebezpe\u010denstv\u00e1 sync_file_range()<\/code> s\u00fa ve\u013emi dobre pop\u00edsan\u00e9 v tom<\/a><\/noindex> materi\u00e1li. Konkr\u00e9tne, zjavne toto volanie pou\u017e\u00edva RocksDB na riadenie toho, kedy jadro vypr\u00e1zd\u0148uje \"\u0161pinav\u00e9\" d\u00e1ta na disk. Ale z\u00e1rove\u0148 tam pre zabezpe\u010denie trval\u00e9ho ukladania \u00fadajov sa pou\u017e\u00edva aj fdatasync()<\/code>. V k\u00f3de<\/a><\/noindex> RocksDB m\u00e1 na t\u00fato t\u00e9mu zauj\u00edmav\u00e9 koment\u00e1re. Napr\u00edklad, zd\u00e1 sa, \u017ee volanie sync_file_range()<\/code> pri pou\u017eit\u00ed ZFS nevedie k vypr\u00e1zdneniu d\u00e1t na disk. Sk\u00fasenos\u0165 mi hovor\u00ed, \u017ee k\u00f3d, ktor\u00fd sa pou\u017e\u00edva zriedka, m\u00f4\u017ee obsahova\u0165 chyby. Preto by som odporu\u010dil nepou\u017e\u00edva\u0165 toto syst\u00e9mov\u00e9 volanie bez ak\u00fatnej potreby.<\/p>\n

Syst\u00e9mov\u00e9 volania, ktor\u00e9 pom\u00e1haj\u00fa zabezpe\u010di\u0165 trval\u00e9 ukladanie \u00fadajov<\/h2>\n

\nDospel som k z\u00e1veru, \u017ee na vykon\u00e1vanie vstupno\/v\u00fdstupn\u00fdch oper\u00e1ci\u00ed zais\u0165uj\u00facich trval\u00e9 ulo\u017eenie d\u00e1t je mo\u017en\u00e9 pou\u017ei\u0165 tri pr\u00edstupy. V\u0161etky si vy\u017eaduj\u00fa zavolanie funkcie fsync()<\/code> pre adres\u00e1r, v ktorom bol s\u00fabor vytvoren\u00fd. Tieto pr\u00edstupy s\u00fa nasledovn\u00e9:<\/p>\n

    \n
  1. Zavolanie funkcie fdatasync()<\/code> alebo fsync()<\/code> po funkcii write()<\/code> (najlep\u0161ie pou\u017e\u00edva\u0165 fdatasync()<\/code>).<\/li>\n
  2. Pr\u00e1ca s popisova\u010dom s\u00faboru, ktor\u00fd je otvoren\u00fd s pr\u00edznakom O_DSYNC<\/code> alebo O_SYNC<\/code> (najlep\u0161ie \u2014 s pr\u00edznakom O_DSYNC<\/code>).<\/li>\n
  3. Pou\u017eitie pr\u00edkazu pwritev2()<\/code> s pr\u00edznakom RWF_DSYNC<\/code> alebo RWF_SYNC<\/code> (preferovanej\u0161ie \u2014 s pr\u00edznakom RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Pozn\u00e1mky o v\u00fdkonnosti<\/h2>\n

    \nNerozumel som presne meraniu v\u00fdkonu r\u00f4znych zo m\u0148a presk\u00faman\u00fdch mechanizmov. Rozdiely v r\u00fdchlosti, ktor\u00e9 som si v\u0161imol, s\u00fa ve\u013emi mal\u00e9. To znamen\u00e1, \u017ee sa m\u00f4\u017eem m\u00fdli\u0165 a to, \u010do v in\u00fdch podmienkach by mohlo prinies\u0165 in\u00e9 v\u00fdsledky. Najprv poviem o tom, \u010do viac ovplyv\u0148uje v\u00fdkon, a potom, o tom, \u010do ovplyv\u0148uje v\u00fdkon menej.<\/p>\n

      \n
    1. Prepisovanie d\u00e1t s\u00faboru je r\u00fdchlej\u0161ie ako prid\u00e1vanie d\u00e1t k s\u00faboru (zisk v v\u00fdkonu m\u00f4\u017ee by\u0165 2-100%). Prid\u00e1vanie d\u00e1t k s\u00faboru si vy\u017eaduje dodato\u010dn\u00e9 zmeny v metad\u00e1tach s\u00faboru, aj po syst\u00e9movom volan\u00ed fallocate()<\/code>, ale ve\u013ekos\u0165 tohto efektu sa m\u00f4\u017ee l\u00ed\u0161i\u0165. Odpor\u00fa\u010dam, aby ste na zabezpe\u010denie najlep\u0161ieho v\u00fdkonu zavolali fallocate()<\/code> na predpr\u00edpravu potrebn\u00e9ho priestoru. Potom je potrebn\u00e9 tento priestor explicitne vyplni\u0165 nulami a zavola\u0165 fsync()<\/code>. V\u010faka tomu bud\u00fa zodpovedaj\u00face bloky vo filesyst\u00e9me ozna\u010den\u00e9 ako 'vyhraden\u00e9', a nie ako 'nevyhraden\u00e9'. To prin\u00e1\u0161a mal\u00e9 (asi 2%) zlep\u0161enie v\u00fdkonu. Navy\u0161e, pri niektor\u00fdch diskoch m\u00f4\u017ee by\u0165 prv\u00e1 oper\u00e1cia pr\u00edstupu k bloku vykonan\u00e1 pomal\u0161ie ako ostatn\u00e9. To znamen\u00e1, \u017ee vyplnenie priestoru nulami m\u00f4\u017ee vies\u0165 k v\u00fdznamn\u00e9mu (asi 100%) zlep\u0161eniu v\u00fdkonu. Osobitne sa to m\u00f4\u017ee sta\u0165 s diskami AWS EBS<\/a><\/noindex> (toto s\u00fa neofici\u00e1lne \u00fadaje, nemohol som ich potvrdi\u0165). To ist\u00e9 sa t\u00fdka aj \u00falo\u017e\u00edsk GCP Persistent Disk<\/a><\/noindex> (a to je u\u017e ofici\u00e1lna inform\u00e1cia, potvrden\u00e1 testami). In\u00ed odborn\u00edci urobili rovnak\u00e9 pozorovania<\/a><\/noindex>, ktor\u00e9 sa t\u00fdkaj\u00fa r\u00f4znych diskov.<\/li>\n
    2. \u010c\u00edm menej syst\u00e9mov\u00fdch volan\u00ed \u2014 t\u00fdm vy\u0161\u0161\u00ed v\u00fdkon (zisk m\u00f4\u017ee by\u0165 okolo 5%). Zd\u00e1 sa, \u017ee volanie open()<\/code> s pr\u00edznakom O_DSYNC<\/code> alebo volanie pwritev2()<\/code> s pr\u00edznakom RWF_SYNC<\/code> je r\u00fdchlej\u0161ie ne\u017e volanie fdatasync()<\/code>Podozrievam, \u017ee za t\u00fdm stoj\u00ed to, \u017ee pri tomto pr\u00edstupe zohr\u00e1va \u00falohu fakt, \u017ee na vyrie\u0161enie tej istej \u00falohy je potrebn\u00e9 vykona\u0165 menej syst\u00e9mov\u00fdch volan\u00ed (jedno volanie namiesto dvoch). Av\u0161ak rozdiel vo v\u00fdkonnosti je ve\u013emi mal\u00fd, tak\u017ee si m\u00f4\u017eete pokojne nev\u0161\u00edma\u0165 a pou\u017ei\u0165 v aplik\u00e1cii to, \u010do nebude vies\u0165 k zlo\u017eitosti jej logiky.<\/li>\n<\/ol>\n

      \nAk v\u00e1s zauj\u00edma t\u00e9ma udr\u017eate\u013en\u00e9ho ukladania \u00fadajov \u2014 tu je nieko\u013eko u\u017eito\u010dn\u00fdch materi\u00e1lov:<\/p>\n