{"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\/lv\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Ilgtsp\u0113j\u012bga datu glab\u0101\u0161ana un Linux failu API","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Es, izp\u0113jot datu glab\u0101\u0161anas iztur\u012bbu m\u0101ko\u0146a sist\u0113m\u0101s, nol\u0113mu p\u0101rbaud\u012bt sevi un p\u0101rliecin\u0101ties, ka saprotu pamata lietas. Es s\u0101ku ar NVMe specifik\u0101cijas las\u012b\u0161anu<\/a><\/noindex> lai noskaidrotu, k\u0101das garantijas attiec\u012bb\u0101 uz iztur\u012bgu datu glab\u0101\u0161anu (proti \u2014 garantijas, ka dati b\u016bs pieejami p\u0113c sist\u0113mas k\u013c\u016bmes) mums sniedz NMVe diski. Es izdar\u012bju \u0161\u0101dus galvenos secin\u0101jumus: no br\u012b\u017ea, kad tiek doti dati ierakst\u012b\u0161anai, l\u012bdz br\u012bdim, kad tie ir pabeigti ierakst\u012b\u0161an\u0101 uz datu nes\u0113ja, j\u0101uzskata, ka dati ir boj\u0101ti. Tom\u0113r liel\u0101kaj\u0101 da\u013c\u0101 datu ierakst\u012b\u0161anas programmu mier\u012bgi tiek izmantoti sist\u0113mas izsaukumi.<\/p>\n

\u0160aj\u0101 materi\u0101l\u0101 es p\u0113tu iztur\u012bga datu glab\u0101\u0161anas meh\u0101nismus, ko nodro\u0161ina Linux failu API. Izskat\u0101s, ka te viss j\u0101b\u016bt vienk\u0101r\u0161i: programma izsauc komandu write()<\/code>, un, kad \u0161\u012bs komandas izpilde pabeigta, dati tiks dro\u0161i saglab\u0101ti disk\u0101. Bet write()<\/code> tikai kop\u0113 lietot\u0101ju datus uz kodola ke\u0161atmi\u0146u, kas atrodas operat\u012bvaj\u0101 atmi\u0146\u0101. Lai piespiedu sist\u0113mu ierakst\u012bt datus uz diska, j\u0101izmanto da\u017ei papildu meh\u0101nismi.<\/p>\n

\"Ilgtsp\u0113j\u012bga<\/a><\/noindex><\/p>\n

Kopum\u0101 \u0161is materi\u0101ls ir piez\u012bmju kopums par to, ko es uzzin\u0101ju par mani interes\u0113jo\u0161o t\u0113mu. Ja \u013coti \u012bsi past\u0101st\u0101m par vissvar\u012bg\u0101ko, tad san\u0101k, ka, lai organiz\u0113tu iztur\u012bgu datu glab\u0101\u0161anu, ir j\u0101izmanto komanda fdatasync()<\/code> vai j\u0101atver faili ar karogu O_DSYNC<\/code>. Ja jums interes\u0113 s\u012bk\u0101k uzzin\u0101t, kas notiek ar datiem ce\u013c\u0101 no programmat\u016bras koda uz disku, ieskatieties \u0161o<\/a><\/noindex> rakst\u0101.
\n<\/a><\/noindex><\/p>\n

funkcijas write() izmanto\u0161anas \u012bpatn\u012bb\u0101s<\/h2>\n

\nSist\u0113mas izsaukums write()<\/code> tiek defin\u0113ts standart\u0101 IEEE POSIX<\/a><\/noindex> k\u0101 m\u0113\u0123in\u0101jums ierakst\u012bt datus faila aprakst\u012bt\u0101j\u0101. P\u0113c veiksm\u012bgas izpildes write()<\/code> datu las\u012b\u0161anas oper\u0101cij\u0101m j\u0101atgrie\u017e tie\u0161i tie biti, kas iepriek\u0161 tika ierakst\u012bti, to veicot pat taj\u0101 gad\u012bjum\u0101, ja dati tiek piek\u013c\u016bti no citiem procesiem vai pavedieniem (\u0161aj\u0101<\/a><\/noindex> atbilsto\u0161\u0101 POSIX standarta sada\u013ca). \u0160eit<\/a><\/noindex>, sada\u013c\u0101, kas velt\u012bta pl\u016bsmu mijiedarb\u012bbai ar parastaj\u0101m failu oper\u0101cij\u0101m, ir piez\u012bme, kur\u0101 teikts, ka, ja katra no div\u0101m pl\u016bsm\u0101m izsauc \u0161\u012bs funkcijas, tad katram izsaukumam j\u0101redz vai nu visas nor\u0101d\u012bt\u0101s sekas, kuras rada cita izsaukuma izpilde, vai ar\u012b neviena sekas. Tas \u013cauj secin\u0101t, ka vis\u0101m ievades\/izvades failu oper\u0101cij\u0101m j\u0101notur resursa blo\u0137\u0113\u0161ana, ar kuru t\u0101s str\u0101d\u0101.<\/p>\n

Vai tas noz\u012bm\u0113, ka oper\u0101cija write()<\/code> ir atom\u0101ra? Tehniski run\u0101jot \u2014 j\u0101. Datu las\u012b\u0161anas oper\u0101cij\u0101m j\u0101atgrie\u017e vai nu viss, vai nekas no t\u0101, kas tika ierakst\u012bts, izmantojot write()<\/code>. Bet oper\u0101cija write()<\/code>, saska\u0146\u0101 ar standartu, nav oblig\u0101ti j\u0101beidzas, ierakstot visu to, ko tai tika pied\u0101v\u0101ts ierakst\u012bt. T\u0101s at\u013cauts ierakst\u012bt tikai da\u013cu datu. Piem\u0113ram, mums var b\u016bt divas pl\u016bsmas, no kur\u0101m katra pievieno 1024 baitus failam, kas aprakst\u012bts ar vienu un to pa\u0161u failu aprakst\u012bt\u0101ju. Standarta ac\u012bs pie\u0146emams b\u016bs rezult\u0101ts, kad katra no rakst\u012b\u0161anas oper\u0101cij\u0101m var\u0113s pievienot failam tikai vienu baitu. \u0160\u012bs oper\u0101cijas paliks atom\u0101ras, ta\u010du, kad t\u0101s beigsies, taj\u0101 fail\u0101 ierakst\u012btie dati b\u016bs sajaukti. \u0160eit<\/a><\/noindex> \u013coti interesanta diskusija par \u0161o t\u0113mu Stack Overflow.<\/p>\n

Funkcijas fsync() un fdatasync()<\/h2>\n

\nVienk\u0101r\u0161\u0101kais veids, k\u0101 nos\u016bt\u012bt datus uz disku, ir izsaukt funkciju fsync()<\/a><\/noindex>. \u0160\u012b funkcija pieprasa oper\u0113t\u0101jsist\u0113mai p\u0101rs\u016bt\u012bt visus modific\u0113tos blokos no ke\u0161atmi\u0146as uz disku. Taj\u0101 ietilpst ar\u012b visi faila metadati (piek\u013cuves laiks, faila modific\u0113\u0161anas laiks utt.). Es uzskatu, ka nepiecie\u0161am\u012bba p\u0113c \u0161iem metadatiem rodas reti, t\u0101p\u0113c, ja j\u016bs zin\u0101t, ka tie jums nav svar\u012bgi, j\u016bs varat izmantot funkciju fdatasync()<\/code>. Iz pal\u012bdz\u012bb\u0101<\/a><\/noindex> par fdatasync()<\/code> teikts, ka t\u0101s funkcijas darb\u012bbas laik\u0101 tiek saglab\u0101ts disk\u0101 t\u0101ds metadatu apjoms, kas \"nepiecie\u0161ams n\u0101kamo datu las\u012b\u0161anas oper\u0101ciju pareizai izpildei\". Un tas ir tie\u0161i tas, kas uztrauc liel\u0101ko da\u013cu lietojumprogrammu.<\/p>\n

Viens no jaut\u0101jumiem, kas \u0161eit var rasties, ir tas, ka \u0161ie meh\u0101nismi negarant\u0113, ka failu var\u0113s atrast p\u0113c iesp\u0113jam\u0101 av\u0101rijas. Proti, ja tiek izveidots jauns fails, ir j\u0101izsauc fsync()<\/code> direktorijai, kur\u0101 tas atrodas. Pret\u0113j\u0101 gad\u012bjum\u0101 p\u0113c av\u0101rijas var izr\u0101d\u012bties, ka \u0161is fails nepast\u0101v. Iemesls tam ir tas, ka UNIX sist\u0113m\u0101s, pateicoties cietajiem saites, failam var b\u016bt vair\u0101kas atra\u0161an\u0101s vietas direktorij\u0101s. T\u0101p\u0113c, izsaucot fsync()<\/code> fails nevar zin\u0101t, kuru tie\u0161i direktoriju vajadz\u0113tu saglab\u0101t disk\u0101 (\u0161eit<\/a><\/noindex> par to var las\u012bt s\u012bk\u0101k). Izr\u0101d\u0101s, ka failu sist\u0113ma ext4 ir sp\u0113j\u012bga autom\u0101tiski<\/a><\/noindex> tikt pielietoti fsync()<\/code> uz direktorij\u0101m, kas satur attiec\u012bgos failus, bet cit\u0101m failu sist\u0113m\u0101m tas var neb\u016bt t\u0101.<\/p>\n

\u0160is meh\u0101nisms var b\u016bt da\u017e\u0101di realiz\u0113ts da\u017e\u0101d\u0101s failu sist\u0113m\u0101s. Es izmantoju blktrace<\/a><\/noindex> lai uzzin\u0101tu, k\u0101das diskoper\u0101cijas tiek izmantotas failu sist\u0113m\u0101s ext4 un XFS. Abas sniedz parastus komandas, kas raksta disk\u0101, gan failu saturu, gan failu sist\u0113mas \u017eurn\u0101lu, izt\u012bra ke\u0161u un pabeidz darbu, veicot FUA rakst\u012b\u0161anu (Force Unit Access, datu rakst\u012b\u0161ana tie\u0161i disk\u0101, apejot ke\u0161u) \u017eurn\u0101l\u0101. Iesp\u0113jams, vi\u0146i tamd\u0113\u013c dara t\u0101, lai apstiprin\u0101tu oper\u0101cijas veik\u0161anu. Diskos, kas neatbalsta FUA, tas izraisa divu ke\u0161u izt\u012br\u012b\u0161anu. Mani eksperimenti par\u0101d\u012bja, ka fdatasync()<\/code> nedaudz \u0101tr\u0101k fsync()<\/code>. R\u012bks blktrace<\/code> nor\u0101da, ka fdatasync()<\/code> parasti raksta disk\u0101 maz\u0101k datu (ext4 fsync()<\/code> ieraksta 20 KiB, bet fdatasync()<\/code> \u2014 16 KiB). Turkl\u0101t es noskaidroju, ka XFS ir nedaudz \u0101tr\u0101ks nek\u0101 ext4. Un \u0161eit ar pal\u012bdz\u012bbu blktrace<\/code> izdev\u0101s noskaidrot, ka fdatasync()<\/code> izmet disk\u0101 maz\u0101k datu (4 KiB XFS).<\/p>\n

Neskaidras situ\u0101cijas, kas rodas, lietojot fsync()<\/h2>\n

\nEs varu atcer\u0113ties tr\u012bs neskaidras situ\u0101cijas, kas saist\u012btas fsync()<\/code>, ar kur\u0101m es sask\u0101ros praks\u0113.<\/p>\n

Pirmais \u0161\u0101ds gad\u012bjums notika 2008. gad\u0101. Tad Firefox 3 interfeiss \u00abiesald\u0113ja\u00bb taj\u0101 gad\u012bjum\u0101, ja notika liela skaita failu rakst\u012b\u0161ana disk\u0101. Probl\u0113ma bija t\u0101, ka interfeisa st\u0101vok\u013ca datu uzglab\u0101\u0161anai tika izmantota SQLite datub\u0101ze. P\u0113c katras izmai\u0146as, kas notika interfeis\u0101, tika izsaukta funkcija fsync()<\/code>, kas sniedza labas garantijas datu stabilai saglab\u0101\u0161anai. Izmantotaj\u0101 failu sist\u0113m\u0101 ext3 funkcija fsync()<\/code> tika tika diska visas \"net\u012br\u0101s\" lapas sist\u0113m\u0101, nevis tikai t\u0101s, kas bija saist\u012btas ar konkr\u0113to failu. Tas noz\u012bm\u0113ja, ka klik\u0161\u0137is uz pogas Firefox var\u0113ja ierosin\u0101t megabaitu datu ierakst\u012b\u0161anu magn\u0113tiskaj\u0101 disk\u0101, kas var\u0113ja aiz\u0146emt daudzas sekundes. Probl\u0113mas risin\u0101jums, cik es sapratu no \u0161ie<\/a><\/noindex> materi\u0101la, bija p\u0101rvietot darbu ar datu b\u0101zi uz asinkronaj\u0101m fonu uzdevumiem. Tas noz\u012bm\u0113, ka iepriek\u0161 Firefox bija ieviesti stingr\u0101ki datu saglab\u0101\u0161anas notur\u012bbas pras\u012bbas, nek\u0101 paties\u012bb\u0101 bija nepiecie\u0161ams, un ext3 failu sist\u0113mas \u012bpatn\u012bbas tikai saasin\u0101ja \u0161o probl\u0113mu.<\/p>\n

Otra nel\u0101ga notik\u0101s 2009. gad\u0101. Toreiz, p\u0113c sist\u0113mas av\u0101rijas, jaun\u0101s ext4 failu sist\u0113mas lietot\u0101ji sask\u0101r\u0101s ar to, ka daudzi nesen izveidotie faili ir ar nulles garumu, bet ar vec\u0101ko ext3 failu sist\u0113mu t\u0101da probl\u0113ma nenotika. Iepriek\u0161\u0113j\u0101 rindkop\u0101 es run\u0101ju par to, ka ext3 diska izsiti p\u0101r\u0101k daudz datu, kas b\u016btiski pal\u0113nin\u0101ja darbu fsync()<\/code>. Lai uzlabotu situ\u0101ciju, ext4 diska izsiti tikai t\u0101s \"net\u012br\u0101s\" lapas, kas ir saist\u012btas ar konkr\u0113to failu. Savuk\u0101rt citu failu dati paliek atmi\u0146\u0101 daudz ilg\u0101k nek\u0101 ar ext3 izmanto\u0161anu. Tas tika izdar\u012bts veiktsp\u0113jas uzlabo\u0161anas nol\u016bkos (p\u0113c noklus\u0113juma dati paliek \u0161\u0101d\u0101 st\u0101vokl\u012b 30 sekundes, \u0161o iestat\u012bjumu var main\u012bt ar dirty_expire_centisecs<\/a><\/noindex>; \u0161eit<\/a><\/noindex> , var atrast papildu materi\u0101lus par \u0161o). Tas noz\u012bm\u0113, ka liels datu apjoms var tikt neatgriezeniski zaud\u0113ts p\u0113c av\u0101rijas. \u0160\u012bs probl\u0113mas risin\u0101jums ir fsync()<\/code> lietojumprogramm\u0101s, kur\u0101m ir nepiecie\u0161ams nodro\u0161in\u0101t datu ilgsto\u0161u saglab\u0101\u0161anu un maksim\u0101li pasarg\u0101t tos no av\u0101riju sek\u0101m. Funkcija fsync()<\/code> str\u0101d\u0101 ar ext4 daudz efekt\u012bv\u0101k nek\u0101 ar ext3. \u0160\u0101 pieejas m\u012bnuss ir tas, ka t\u0101s izmanto\u0161ana, t\u0101pat k\u0101 iepriek\u0161, pal\u0113nina da\u017eu oper\u0101ciju izpildi, piem\u0113ram, programmu instal\u0101ciju. S\u012bk\u0101ku inform\u0101ciju par to skatiet \u0161eit<\/a><\/noindex> un \u0161eit<\/a><\/noindex>.<\/p>\n

Tre\u0161\u0101 probl\u0113ma, kas attiecas uz fsync()<\/code>, rad\u0101s 2018. gad\u0101. Toreiz, PostgreSQL projekta ietvaros, tika noskaidrots, ka, ja funkcija fsync()<\/code> saskaras ar k\u013c\u016bdu, t\u0101 atz\u012bm\u0113 \"net\u012br\u0101s\" lapas k\u0101 \"t\u012bras\". Rezult\u0101t\u0101 n\u0101kamie izsaukumi fsync()<\/code> nekas ar \u0161\u0101d\u0101m lap\u0101m netiek dar\u012bts. T\u0101p\u0113c modific\u0113t\u0101s lapas tiek glab\u0101tas atmi\u0146\u0101 un nekad netiek ierakst\u012btas disk\u0101. Tas ir \u012bsta katastrofa, jo lietotne uzskat\u012bs, ka da\u017ei dati ir ierakst\u012bti disk\u0101, bet paties\u012bb\u0101 t\u0101 neb\u016bs. \u0160\u0101di trauc\u0113jumi fsync()<\/code> ir reti sastopami, lietotne \u0161\u0101d\u0101s situ\u0101cij\u0101s gandr\u012bz neko nevar dar\u012bt, lai c\u012bn\u012btos pret probl\u0113mu. M\u016bsdien\u0101s, kad tas notiek, PostgreSQL un citas lietotnes avar\u0113. \u0160eit<\/a><\/noindex>, materi\u0101l\u0101 \u00abVai lietotnes var atg\u016bt no fsync k\u013c\u016bd\u0101m?\u00bb, \u0161\u012b probl\u0113ma ir p\u0113t\u012bta visos s\u012bkumos. Pa\u0161laik lab\u0101kais risin\u0101jums \u0161ai probl\u0113mai ir izmantot Direct I\/O ar karogu O_SYNC<\/code> vai ar karogu O_DSYNC<\/code>. Izmantojot \u0161o pieeju, sist\u0113ma zi\u0146os par k\u013c\u016bd\u0101m, kas var rasties, veicot konkr\u0113tas datu ierakst\u012b\u0161anas oper\u0101cijas, bet \u0161\u012b pieeja prasa, lai lietotne pati p\u0101rvald\u012btu buferus. Par to lasiet \u0161eit<\/a><\/noindex> un \u0161eit<\/a><\/noindex>.<\/p>\n

Failu atv\u0113r\u0161ana, izmantojot karogus O_SYNC un O_DSYNC<\/h2>\n

\nAtgriez\u012bsimies pie diskusiju par Linux meh\u0101nismiem, kas nodro\u0161ina datu notur\u012bgu glab\u0101\u0161anu. Proti, runa ir par karoga izmanto\u0161anu O_SYNC<\/code> vai karoga O_DSYNC<\/code> failu atv\u0113r\u0161an\u0101, izmantojot sist\u0113mas izsaukumu open()<\/a><\/noindex>. Izmantojot \u0161o pieeju, katra datu ierakst\u012b\u0161anas oper\u0101cija tiek veikta t\u0101, it k\u0101 p\u0113c katras komandas write()<\/code> sist\u0113m\u0101 tiek dotas attiec\u012bgi komandas fsync()<\/code> un fdatasync()<\/code>. Iz POSIX specifik\u0101cij\u0101s<\/a><\/noindex> to d\u0113v\u0113 par \u00abSak\u0101rtotu I\/O failu integrit\u0101tes pabeig\u0161anu\u00bb un \u00abDatu integrit\u0101tes pabeig\u0161anu\u00bb. Galven\u0101 \u0161\u012b pieejas priek\u0161roc\u012bba ir t\u0101, ka datu integrit\u0101tes nodro\u0161in\u0101\u0161anai j\u0101veic tikai viens sist\u0113mas izsaukums, nevis divi (piem\u0113ram \u2014 write()<\/code> un fdatasync()<\/code>). Galvenais \u0161\u012bs pieejas tr\u016bkums ir tas, ka visas ierakst\u012b\u0161anas oper\u0101cijas, kas izmanto attiec\u012bgo faila deskriptoru, tiks sinhroniz\u0113tas, kas var ierobe\u017eot lietotnes koda strukt\u016bras iesp\u0113jas.<\/p>\n

Izmanto\u0161ana Direct I\/O ar karogu O_DIRECT<\/h2>\n

\nSist\u0113mas izsaukums open()<\/code> atbalsta karogu O_DIRECT<\/code>, kas paredz\u0113ts tam, lai, apejot oper\u0101cijas sist\u0113mas ke\u0161u, veiktu ievades-izvades oper\u0101cijas, tie\u0161i sadarbojoties ar disku. Tas, daudzu gad\u012bjumu, noz\u012bm\u0113, ka ierakst\u012b\u0161anas komandas, ko izplata programma, tiks tie\u0161i p\u0101rveidotas par komand\u0101m, kas v\u0113rstas uz darbu ar disku. Bet, visp\u0101r\u012bgi, \u0161is meh\u0101nisms nav aizst\u0101\u0161ana funkcij\u0101m fsync()<\/code> vai fdatasync()<\/code>. Probl\u0113ma ir t\u0101da, ka pats disks var atlikt vai ke\u0161ot<\/a><\/noindex> atbilsto\u0161\u0101s datu ierakst\u012b\u0161anas komandas. Un, kas v\u0113l slikt\u0101k, noteiktos \u012bpa\u0161os gad\u012bjumos ievades-izvades oper\u0101cijas, kas veiktas, izmantojot karogu O_DIRECT<\/code>, tiek p\u0101rs\u016bt\u012btas<\/a><\/noindex> tradicion\u0101laj\u0101s buferiz\u0113taj\u0101s oper\u0101cij\u0101s. \u0160o probl\u0113mu visviegl\u0101k var atrisin\u0101t, izmantojot failu atv\u0113r\u0161anai ar\u012b karogu O_DSYNC<\/code>, kas noz\u012bm\u0113s, ka katrai ierakst\u012b\u0161anas oper\u0101cijai sekos izsaukums fdatasync()<\/code>.<\/p>\n

Izr\u0101d\u0101s, ka XFS failu sist\u0113m\u0101 nesen ir pievienota \"\u0101tr\u0101 pieeja\" O_DIRECT|O_DSYNC<\/code>-datu ierakstiem. Ja p\u0101rraksta bloku, izmantojot O_DIRECT|O_DSYNC<\/code>, tad XFS, nevis iztuk\u0161ojot ke\u0161u, izpild\u012bs FUA ierakst\u012b\u0161anas komandu, ja iek\u0101rta to atbalsta. Es to p\u0101rbaud\u012bju, izmantojot util\u012btu blktrace<\/code> Linux 5.4 \/ Ubuntu 20.04 sist\u0113m\u0101. \u0160\u0101da pieeja b\u016btu efekt\u012bv\u0101ka, jo t\u0101s izmanto\u0161anas gad\u012bjum\u0101 disk\u0101 tiek ierakst\u012bts minim\u0101ls datu daudzums, un tiek veikta viena oper\u0101cija, nevis divas (ieraksts un ke\u0161atmi\u0146as iztuk\u0161o\u0161ana). Es atradu saiti uz pl\u0101ksne<\/a><\/noindex> 2018. gada kodu, kur\u0101 tika \u012bstenots \u0161is meh\u0101nisms. Tur ir diskusija par \u0161\u012bs optimiz\u0101cijas pielieto\u0161anu ar\u012b cit\u0101s failu sist\u0113m\u0101s, ta\u010du, cik man zin\u0101ms, XFS ir pagaid\u0101m vien\u012bg\u0101 failu sist\u0113ma, kas to atbalsta.<\/p>\n

sync_file_range() funkcija<\/h2>\n

\nLinux ir sist\u0113mas izsaukums sync_file_range()<\/a><\/noindex>, kas \u013cauj iztuk\u0161ot disk\u0101 tikai da\u013cu no faila, nevis visu failu. \u0160is izsaukums inici\u0113 asinkrono datu iztuk\u0161o\u0161anu un negaida t\u0101s pabeig\u0161anu. Bet, k\u0101 min\u0113ts sync_file_range()<\/code> , \u0161is r\u012bks ir \"\u013coti b\u012bstams\". T\u0101 lieto\u0161ana nav ieteicama. \u012apa\u0161\u012bbas un b\u012bstam\u012bbas sync_file_range()<\/code> ir \u013coti labi aprakst\u012btas this<\/a><\/noindex> materi\u0101l\u0101. \u012apa\u0161i, \u0161\u0137iet, ka \u0161is izsaukums izmanto RocksDB, lai p\u0101rvald\u012btu, kad kods iztuk\u0161o \"net\u012bros\" datus disk\u0101. Tom\u0113r tur, lai nodro\u0161in\u0101tu stabilu datu glab\u0101\u0161anu, tiek izmantots ar\u012b fdatasync()<\/code>. Iz kode<\/a><\/noindex> RocksDB ir interesantas piez\u012bmes par \u0161o t\u0113mu. Piem\u0113ram, \u0161\u0137iet, ka izsaukums sync_file_range()<\/code> izmantojot ZFS, nenoved pie datu iztuk\u0161o\u0161anas disk\u0101. Mans pieredze liecina, ka kods, ko izmanto reti, iesp\u0113jams, satur k\u013c\u016bdas. T\u0101p\u0113c es ieteiktu nelietot \u0161o sist\u0113mas izsaukumu bez absol\u016btas nepiecie\u0161am\u012bbas.<\/p>\n

Sist\u0113mas izsaukumi, kas pal\u012bdz nodro\u0161in\u0101t stabilu datu glab\u0101\u0161anu<\/h2>\n

\nEs non\u0101cu, ka tr\u012bs pieejas var izmantot, lai veiktu ievades\/izvades oper\u0101cijas, kas nodro\u0161ina notur\u012bgu datu glab\u0101\u0161anu. Viss prasa izsaukt funkciju fsync()<\/code> direktorij\u0101, kur\u0101 ir izveidots fails. \u0160\u012bs ir pieejas:<\/p>\n

    \n
  1. Funkcijas izsaukums fdatasync()<\/code> vai fsync()<\/code> p\u0113c funkcijas write()<\/code> (velams izmantot fdatasync()<\/code>).<\/li>\n
  2. Darbs ar faila deskriptoru, kas atv\u0113rts ar karogu O_DSYNC<\/code> vai O_SYNC<\/code> (lab\u0101k \u2014 ar karogu O_DSYNC<\/code>).<\/li>\n
  3. Komandas izmanto\u0161ana pwritev2()<\/code> ar atz\u012bmi RWF_DSYNC<\/code> vai RWF_SYNC<\/code> (priek\u0161roka \u2014 ar karogu RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Veiktsp\u0113jas piez\u012bmes<\/h2>\n

    \nEs neesmu veicis r\u016bp\u012bgu da\u017e\u0101du man\u0101 p\u0113t\u012bjum\u0101 iepaz\u012bto meh\u0101nismu veiktsp\u0113jas m\u0113r\u012bjumu. Mani uztvertie \u0101truma at\u0161\u0137ir\u012bbas ir diezgan niec\u012bgas. Tas noz\u012bm\u0113, ka es varu k\u013c\u016bd\u012bties, un, ka citos apst\u0101k\u013cos tas pats var rad\u012bt citus rezult\u0101tus. Visupirms es past\u0101st\u012b\u0161u par to, kas ietekm\u0113 veiktsp\u0113ju vair\u0101k, bet p\u0113c tam, par to, kas ietekm\u0113 veiktsp\u0113ju maz\u0101k.<\/p>\n

      \n
    1. Datu p\u0101rrakst\u012b\u0161ana fail\u0101 ir \u0101tr\u0101ka nek\u0101 datu pievieno\u0161ana failam (veiktsp\u0113jas ieguvums var b\u016bt no 2-100%). Datu pievieno\u0161ana failam prasa veikt papildu izmai\u0146as faila metadatos, pat p\u0113c sist\u0113mas izsaukuma fallocate()<\/code>, bet \u0161\u012b efekta apjoms var main\u012bties. Es iesaku, lai nodro\u0161in\u0101tu lab\u0101ko veiktsp\u0113ju, izsaukt fallocate()<\/code> lai iepriek\u0161\u0113ji rezerv\u0113tu nepiecie\u0161amo telpu. P\u0113c tam \u0161\u012b telpa j\u0101aizpilda ar null\u0113m un j\u0101izsauc fsync()<\/code>. Pateicoties tam, attiec\u012bgie bloki failu sist\u0113m\u0101 tiks mar\u0137\u0113ti k\u0101 \"rezerv\u0113ti\", nevis k\u0101 \"nereserv\u0113ti\". Tas nodro\u0161ina nelielu (apm\u0113ram 2%) veiktsp\u0113jas uzlabo\u0161anu. Turkl\u0101t da\u017eiem diskam pirm\u0101 piek\u013cuves oper\u0101cija blokam var notikt l\u0113n\u0101k nek\u0101 cit\u0101m. Tas noz\u012bm\u0113, ka telpas aizpild\u012b\u0161ana ar null\u0113m var rad\u012bt iev\u0113rojamu (apm\u0113ram 100%) veiktsp\u0113jas uzlabo\u0161anu. \u012apa\u0161i tas var notikt diskos AWS EBS<\/a><\/noindex> (\u0161ie ir neofici\u0101li dati, kurus es nevar\u0113ju apstiprin\u0101t). Tas pats attiecas ar\u012b uz kr\u0101tuv\u0113m GCP Persistent Disk<\/a><\/noindex> (un \u0161ie ir ofici\u0101li dati, ko apstiprin\u0101ju\u0161i testi). Citi speci\u0101listi ir veiku\u0161i l\u012bdz\u012bgas nov\u0113ro\u0161anas<\/a><\/noindex>, kas attiecas uz da\u017e\u0101diem diskiem.<\/li>\n
    2. Jo maz\u0101k sist\u0113mas izsaukumu, jo augst\u0101ka veiktsp\u0113ja (ieg\u016b\u0161ana var b\u016bt apm\u0113ram 5%). Izskat\u0101s, ka izsaukums open()<\/code> ar atz\u012bmi O_DSYNC<\/code> vai izsaukums pwritev2()<\/code> ar atz\u012bmi RWF_SYNC<\/code> ir \u0101tr\u0101k nek\u0101 izsaukums fdatasync()<\/code>P\u0101rliecin\u0101jos, ka \u0161eit loma ir tas, ka \u0161\u0101ds pieejas veids noz\u012bm\u0113, ka, lai atrisin\u0101tu to pa\u0161u uzdevumu, ir j\u0101veic maz\u0101k sist\u0113mas izsaukumu (viens izsaukums, nevis divi). Ta\u010du veiktsp\u0113jas at\u0161\u0137ir\u012bba ir \u013coti maza, t\u0101p\u0113c j\u016bs varat to piln\u012bgi ignor\u0113t un lietot aplik\u0101cij\u0101 to, kas nenoved\u012bs pie t\u0101s lo\u0123ikas sare\u017e\u0123\u012b\u0161anas.<\/li>\n<\/ol>\n

      \nJa j\u016bs interes\u0113 ilgtsp\u0113j\u012bgas datu glab\u0101\u0161anas t\u0113ma \u2014 \u0161eit ir da\u017eas noder\u012bgas materis\u0101ls:<\/p>\n