{"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\/et\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"P\u00fcsiv andmete ja failide API Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Olen uurinud andmete salvestamise usaldusv\u00e4\u00e4rsust pilves\u00fcsteemides ja olen otsustanud end proovile panna, et aru saada, kas ma m\u00f5istan p\u00f5hilisi aspekte. Ma alustasin NVMe spetsifikatsiooni lugemisest<\/a><\/noindex> , et m\u00f5ista, milliseid tagatisi p\u00fcsiva andmete salvestamise kohta (st tagatisi, et andmed on saadaval p\u00e4rast s\u00fcsteemi riket) pakuvad NMVe kettad. J\u00f5udsin j\u00e4rgmistele peamistele j\u00e4reldustele: andmeid tuleb pidada rikutuks hetkel, kui on antud andmete kirjutamise k\u00e4sk, ja kuni hetkeni, mil nende kirjutamine andmekandjale l\u00f5petatakse. Siiski, enamikus andmete kirjutamise programmides kasutatakse v\u00e4ga rahulikult s\u00fcsteemi v\u00e4ljakutseid.<\/p>\n

K\u00e4esolevas materjalis uurin p\u00fcsivate andmete salvestamise mehhanisme, mida pakuvad Linuxi failide API-d. Tundub, et siin peaks k\u00f5ik olema lihtne: programm kutsub v\u00e4lja k\u00e4su write()<\/code>, ja p\u00e4rast selle k\u00e4su t\u00e4itmist peaksid andmed olema usaldusv\u00e4\u00e4rselt salvestatud kettale. Kuid write()<\/code> see lihtsalt kopeerib rakenduse andmed tuuma vahem\u00e4llu, mis asub aktiivses m\u00e4lus. Et sundida s\u00fcsteemi andmeid kettale kirjutama, tuleb kasutada m\u00f5ningaid t\u00e4iendavaid mehhanisme.<\/p>\n

\"P\u00fcsiv<\/a><\/noindex><\/p>\n

\u00dcldiselt on see materjal kogumik m\u00e4rkmeid, mis k\u00e4sitlevad seda, mida ma huvitaval teemal \u00f5ppisin. Kui v\u00e4ga l\u00fchidalt r\u00e4\u00e4kida k\u00f5ige olulisemast, siis selgub, et p\u00fcsiva andmete salvestamise korraldamiseks tuleb kasutada k\u00e4sku fdatasync()<\/code> v\u00f5i avada faile flagi O_DSYNC<\/code>abil. Kui teid huvitab \u00fcksikasjalik \u00fclevaade sellest, mis juhtub andmetega teel programmikoodist kettale, vaadake seda<\/a><\/noindex> artiklit.
\n<\/a><\/noindex><\/p>\n

write() funktsiooni kasutamise erip\u00e4rad<\/h2>\n

\nS\u00fcsteemi v\u00e4ljakutse write()<\/code> on m\u00e4\u00e4ratletud standardis IEEE POSIX<\/a><\/noindex> kui katse andmete kirjutamiseks failide deskiptorisse. P\u00e4rast operatsiooni edukat l\u00f5petamist write()<\/code> peavad andmete lugemise toimingud tagastama t\u00e4pselt need baitid, mis olid eelnevalt kirjutatud, isegi juhul, kui andmetele p\u00e4\u00e4sevad ligi teised protsessid v\u00f5i l\u00f5imed (siin on<\/a><\/noindex> vastav POSIXi standardi osa). Siin<\/a><\/noindex>, jaotises, mis k\u00e4sitleb voogude suhtlemist tavaliste failitegevustega, on m\u00e4rge, kus \u00f6eldakse, et kui iga voog kutsub neid funktsioone v\u00e4lja, peab iga v\u00e4ljakutse n\u00e4gema kas k\u00f5iki m\u00e4\u00e4ratud tagaj\u00e4rgi, mida p\u00f5hjustab muu v\u00e4ljakutse t\u00e4itmine, v\u00f5i ei n\u00e4e mitte \u00fchtegi tagaj\u00e4rge. See v\u00f5imaldab j\u00e4reldada, et k\u00f5ik sisendi\/v\u00e4ljundi failitegevused peavad hoidma ressursi lukus, millega nad t\u00f6\u00f6tavad.<\/p>\n

Kas see t\u00e4hendab, et operatsioon write()<\/code> on aatomaarne? Tehniliselt \u2014 jah. Andmete lugemise operatsioonid peaksid tagastama kas k\u00f5ik v\u00f5i mitte midagi sellest, mis on kirjutatud funktsiooni write()<\/code>. Kuid operatsioon write()<\/code>, vastavalt standardile, ei pea tingimata l\u00f5pule viima, kirjutades k\u00f5ik, mis tal oli ette n\u00e4htud kirjutada. Tal on lubatud kirjutada ainult osa andmeid. N\u00e4iteks v\u00f5ib meil olla kaks voogu, iga\u00fcks, kes lisab 1024 baiti faili, millel on sama failihaldur. Standardi kohaselt on vastuv\u00f5etav tulemus, kui iga kirjutamisoperatsioon suudab faili lisada vaid \u00fche baiti. Need operatsioonid j\u00e4\u00e4vad aatomaarseks, kuid nende l\u00f5puleviimisel on neile kirjutatud andmed failis segamini. Siin<\/a><\/noindex> Sellel teemal on v\u00e4ga huvitav arutelu Stack Overflow's.<\/p>\n

Funktsioonid fsync() ja fdatasync()<\/h2>\n

\nLihtsaim viis andmete kettale kirjutamiseks on funktsiooni v\u00e4ljakutse fsync()<\/a><\/noindex>. See funktsioon taotleb operatsioonis\u00fcsteemilt k\u00f5igi muudetud plokkide edastamist vahem\u00e4lust kettale. Siia kuuluvad ka k\u00f5ik faili metaandmed (j\u00f5udmisaja, faili muutmise aeg jne). Ma usun, et nende metaandmete vajadus tekib harva, seega kui teate, et need ei ole teile olulised, v\u00f5ite kasutada funktsiooni fdatasync()<\/code>. Failis abi<\/a><\/noindex> 6TB fdatasync()<\/code> \u00fctleb, et selle funktsiooni t\u00f6\u00f6 k\u00e4igus salvestatakse kettale nii palju metaandmeid, kui on \"vajalik j\u00e4rgmiste andmete lugemise operatsioonide korrektseks teostamiseks\". Ja see on t\u00e4pselt see, mis enamiku rakenduste jaoks muret tekitab.<\/p>\n

\u00dcks probleem, mis siit v\u00f5ib tekkida, on see, et need mehhanismid ei garanteeri, et faili saab p\u00e4rast v\u00f5imalikku riket leida. Eriti siis, kui luuakse uus fail, tuleb v\u00e4ljakutse teha fsync()<\/code> katalooge, mis seda sisaldab. Vastasel juhul v\u00f5ib p\u00e4rast t\u00f5rget juhtuda, et seda faili ei eksisteeri. Selle p\u00f5hjuseks on asjaolu, et UNIXis, tugevate linkide kasutamise t\u00f5ttu, v\u00f5ib fail eksisteerida mitmes kataloogis. Seet\u00f5ttu kutsutakse esile fsync()<\/code> faili jaoks pole v\u00f5imalust teada, milliste kataloogide andmeid tuleb samuti kettale kirjutada (siit<\/a><\/noindex> sellest saab lugeda l\u00e4hemalt). Tundub, et failis\u00fcsteem ext4 on v\u00f5imeline automaatne<\/a><\/noindex> rakendama fsync()<\/code> kataloogidesse, mis sisaldavad vastavaid faile, kuid teiste failis\u00fcsteemide puhul ei pruugi see nii olla.<\/p>\n

Seda mehhanismi v\u00f5ib erinevates failis\u00fcsteemides eri viisil rakendada. Ma kasutasin blktrace'i<\/a><\/noindex> selgitamaks, milliseid kettategevusi kasutatakse failis\u00fcsteemides ext4 ja XFS. M\u00f5lemad annavad tavalised kettale kirjutamise k\u00e4sud nii failide sisu kui ka failis\u00fcsteemi \u017eurnali jaoks, kirjutavad vahem\u00e4lud t\u00fchjaks ja l\u00f5petavad t\u00f6\u00f6tamise, teostades FUA-kirjutamise (Force Unit Access, andmete kirjutamine otse kettale, vahe m\u00e4lu vahele k\u00fcsimata) \u017eurnali. T\u00f5en\u00e4oliselt k\u00e4ituvad nad nii, et kinnitada operatsiooni teostamise fakti. Kettadel, mis ei toeta FUA-d, tekitab see kaks vahem\u00e4lu t\u00fchjendust. Minu katsed n\u00e4itasid, et fdatasync()<\/code> veidi kiiremini fsync()<\/code>. Utiliit blktrace'i<\/code> j\u00e4tab mulje, et fdatasync()<\/code> kirjutab tavaliselt kettale v\u00e4hem andmeid (ext4 fsync()<\/code> kirjutab 20 KiB, samas kui fdatasync()<\/code> \u2014 16 KiB). Lisaks avastasin, et XFS on veidi kiirem kui ext4. Ja siin sain blktrace'i<\/code> teada, et fdatasync()<\/code> kirjutab kettale v\u00e4hem andmeid (4 KiB XFS-is).<\/p>\n

Ebamugavad olukorrad, mis tekivad fsync() kasutamisel<\/h2>\n

\nMulle tuleb meelde kolm ebamugavat olukorda, mis on seotud fsync()<\/code>, millega ma olen praktikas kokku puutunud.<\/p>\n

Esimene selline juhtum toimus 2008. aastal. Sel ajal \u2018j\u00e4i\u2019 Firefox 3 kasutajaliides seisma, kui kirjutati kettale palju faile. Probleem oli selles, et liidese oleku teabe salvestamiseks kasutati SQLite andmebaasi. P\u00e4rast iga muudatust, mis toimus liideses, kutsuti v\u00e4lja funktsioon fsync()<\/code>, mis pakkus head garantiid andmete p\u00fcsiva hoidmise osas. Tol ajal kasutatud failis\u00fcsteemis ext3 funktsioon fsync()<\/code> salvestas s\u00fcsteemis k\u00f5ik \u201er\u00e4pased\u201c lehed, mitte ainult need, mis olid seotud vastava failiga. See t\u00e4hendas, et hiirekl\u00f5ps Firefoxis v\u00f5is algatada megabaidise andmete salvestamise magnetketta peale, mis v\u00f5is v\u00f5tta palju sekundeid. Probleemi lahendus, nii nagu ma aru sain, oli selle<\/a><\/noindex> materjalist, et andmebaasihalduse viimine as\u00fcnkroonsetesse taustat\u00f6\u00f6desse oli vajalik. See t\u00e4hendab, et varem olid Firefoxis rakendatud rangemad andmete salvestamise vastupidavuse n\u00f5uded, kui see tegelikult vajalik oli, ja ext3 failis\u00fcsteemi omadused halvendavad seda probleemi veelgi.<\/p>\n

Teine vastuolu tekkis 2009. aastal. Siis, p\u00e4rast s\u00fcsteemi nurjumist, leidsid uue ext4 failis\u00fcsteemi kasutajad, et paljud hiljuti loodud failid on nullpikkusega, kuid vanema ext3 failis\u00fcsteemi puhul ei toimunud sellist asja. Eelmises l\u00f5igus r\u00e4\u00e4kisin, et ext3 salvestas kettale liiga palju andmeid, mis aeglustas oluliselt fsync()<\/code>t\u00f6\u00f6d. Situatsiooni parandamiseks salvestab ext4 kettale ainult need \u201er\u00e4pased\u201c lehed, mis on seotud konkreetse failiga. Teiste failide andmed j\u00e4\u00e4vad m\u00e4lu sisse palju pikemaks ajaks kui ext3 kasutamisel. See tehti j\u00f5udluse parandamiseks (vaikimisi on andmed sellises olekus 30 sekundit, seda saab seadistada dirty_expire_centisecs<\/a><\/noindex>; siit<\/a><\/noindex> leiate t\u00e4iendavat teavet selle kohta). See t\u00e4hendab, et suurel andmemahtude puhul v\u00f5ivad andmed olla p\u00e4rast s\u00fcsteemiviga p\u00f6\u00f6rdumatult kadunud. Selle probleemi lahendus seisneb selle kasutamises fsync()<\/code> rakendustes, mis peavad tagama usaldusv\u00e4\u00e4rse andmesalvestuse ja maksimaalselt kaitsta neid t\u00f5rgete tagaj\u00e4rgede eest. Funktsioon fsync()<\/code> toimib ext4 kasutamisel palju t\u00f5husamalt kui ext3 kasutamisel. Selle l\u00e4henemise miinus on see, et selle rakendamine aeglustab, nagu ennegi, teatud toimingute t\u00e4itmist, n\u00e4iteks programmide installimist. \u00dcksikasjad selle kohta leiate siin<\/a><\/noindex> ja siin<\/a><\/noindex>.<\/p>\n

Kolmas probleem, mis fsync()<\/code>, kerkis esile 2018. aastal. Sel ajal, PostgreSQL projekti raames, selgitati v\u00e4lja, et kui funktsioon fsync()<\/code> kohtab viga, m\u00e4rgib see \u201er\u00e4pased\u201c lehed kui \u201epuhtad\u201c. Seet\u00f5ttu j\u00e4rgmised v\u00e4ljakutsed fsync()<\/code> Selliseid lehti ei tehta midagi. Seet\u00f5ttu s\u00e4ilivad muudetud lehed m\u00e4lu piires ja neid ei salvestata kunagi kettale. See on t\u00f5eline katastroof, kuna rakendus usub, et teatud andmed on kettale salvestatud, kuigi tegelikult see ei ole nii. Sellised vead fsync()<\/code> esinevad harva, rakendus sellistes olukordades peaaegu ei saa probleemi lahendamiseks midagi ette v\u00f5tta. T\u00e4nap\u00e4eval, kui see juhtub, katkestavad PostgreSQL ja teised rakendused oma t\u00f6\u00f6. Siin<\/a><\/noindex>, artiklis \u201eKas rakendused saavad fsynci t\u00f5rgetest taastuda?\u201d, uuritakse seda probleemi \u00fcksikasjalikult. Praegu on parim lahendus selle probleemi jaoks kasutada Direct I\/O koos lipuga O_SYNC<\/code> v\u00f5i lipuga O_DSYNC<\/code>. Sellise l\u00e4henemise korral teatab s\u00fcsteem vigu, mis v\u00f5ivad tekkida andmete kirjutamise konkreetsete operatsioonide t\u00e4itmisel, kuid see l\u00e4henemine n\u00f5uab, et rakendus haldaks puhverdamist ise. Lisateavet selle kohta lugege siin<\/a><\/noindex> ja siin<\/a><\/noindex>.<\/p>\n

Failide avamine O_SYNC ja O_DSYNC lippudega<\/h2>\n

\nNaaseme arutelu juurde Linuxi mehhanismide kohta, mis tagavad andmete p\u00fcsiva salvestamise. Nimelt r\u00e4\u00e4gime me lipu kasutamisest O_SYNC<\/code> v\u00f5i lipu O_DSYNC<\/code> failide avamisel s\u00fcsteemi s\u00fcsteemik\u00f5nes open()<\/a><\/noindex>. Sellise l\u00e4henemise korral toimub iga andmete kirjutamise toiming nii, nagu oleks p\u00e4rast iga k\u00e4sku write()<\/code> s\u00fcsteemile antud vastavalt k\u00e4sud fsync()<\/code> ja fdatasync()<\/code>. Failis POSIXi spetsifikatsioon<\/a><\/noindex> nii \u00f6eldakse \"S\u00fcnkroniseeritud I\/O Faili Terviklikkuse T\u00e4itmine\" ja \"Andmete Terviklikkuse T\u00e4itmine\". Selle l\u00e4henemise peamine eelis on see, et andmete terviklikkuse tagamiseks peab toimuma ainult \u00fcks s\u00fcsteemi k\u00f5ne, mitte kaks (n\u00e4iteks \u2014 write()<\/code> ja fdatasync()<\/code>). Selle l\u00e4henemise peamine puudus on see, et k\u00f5ik kirjutamisoperatsioonid, mis kasutavad vastavat failikirjet, s\u00fcnkroniseeritakse, mis v\u00f5ib piirata rakenduse koodi struktureerimise v\u00f5imalusi.<\/p>\n

Direct I\/O kasutamine O_DIRECT lipuga<\/h2>\n

\nS\u00fcsteemi v\u00e4ljakutse open()<\/code> toetab lippu O_DIRECT<\/code>, mis on m\u00f5eldud selleks, et m\u00f6\u00f6da minna operatsioonis\u00fcsteemi vahem\u00e4lust ning teostada sisendi-v\u00e4ljundi toiminguid, suheldes otse ketastega. See t\u00e4hendab paljudes olukordades, et programmi poolt antud kirjutamisk\u00e4sked t\u00f5lgitakse otse ketastele suunatud k\u00e4skudeks. Kuid \u00fcldiselt ei asenda see mehhanism funktsioone fsync()<\/code> v\u00f5i fdatasync()<\/code>. Asi on selles, et ise kettas v\u00f5ib t\u00e4htsustada v\u00f5i vahem\u00e4lu<\/a><\/noindex> vastavaid andmete salvestamise k\u00e4sklusi. Ja mis veel hullem, m\u00f5ningatel erijuhtudel sisendi-v\u00e4ljundi toimingud, mida viiakse l\u00e4bi lipu kasutamisel O_DIRECT<\/code>, edastatakse<\/a><\/noindex> traditsioonilistesse puhvrifunktsioonidesse. Selle probleemi lihtsaim lahendus on kasutada failide avamisel ka lippu O_DSYNC<\/code>, mis t\u00e4hendab, et iga salvestamistoiminguga kaasneb kutse fdatasync()<\/code>.<\/p>\n

Leiti, et XFS failis\u00fcsteemisse on hiljuti lisatud \"kiire tee\" O_DIRECT|O_DSYNC<\/code>-andmete salvestamiseks. Kui bloke peatatakse, kasutades O_DIRECT|O_DSYNC<\/code>, siis XFS, selle asemel et vahem\u00e4lu t\u00fchjendada, viib l\u00e4bi FUA-salvestamise k\u00e4su, kui seade seda toetab. Ma olen seda veendunud, kasutades t\u00f6\u00f6riista blktrace'i<\/code> Linuxis 5.4 \/ Ubuntu 20.04. Selline l\u00e4henemine peaks olema efektiivsem, kuna selle kasutamisel salvestatakse kettale minimaalne andmemahu hulk ja rakendatakse \u00fchte operatsiooni, mitte kahte (salvestamine ja vahem\u00e4lu t\u00fchjendamine). Leidsin viite pat\u0161<\/a><\/noindex> 2018. aasta tuumale, milles see mehhanism on rakendatud. Seal on arutelu selle optimeerimise rakendamise kohta ka teistes failis\u00fcsteemides, kuid niipalju kui ma tean, on XFS praegu ainus failis\u00fcsteem, mis seda toetab.<\/p>\n

funktsioon sync_file_range()<\/h2>\n

\nLinuxis on s\u00fcsteemikutsumus sync_file_range()<\/a><\/noindex>, mis v\u00f5imaldab salvestada kettale vaid osa failist, mitte kogu faili. See kutsung algatab as\u00fcnkroonse andmete t\u00fchjendamise ja ei oota selle l\u00f5petamist. Kuid juhendis sync_file_range()<\/code> \u00f6eldakse, et see k\u00e4sk on \"v\u00e4ga ohtlik\". Selle kasutamist ei soovitata. Omadused ja ohud sync_file_range()<\/code> on v\u00e4ga h\u00e4sti kirjeldatud selles<\/a><\/noindex> materjalis. Eelk\u00f5ige n\u00e4ib, et see kutse kasutab RocksDB-d selleks, et hallata, millal tuum t\u00fchjendab \"mustad\" andmed kettale. Kuid samal ajal kasutatakse seal andmete p\u00fcsimise tagamiseks ka fdatasync()<\/code>. Failis koodis<\/a><\/noindex> RocksDB-s on selle teema kohta huvitavad kommentaarid. N\u00e4iteks tundub, et kutse sync_file_range()<\/code> kasutades ZFS ei viibi andmete t\u00fchjendamiseni kettale. Kogemus vihjab, et harva kasutatav kood v\u00f5ib sisaldada vigu. Seet\u00f5ttu soovitaksin seda s\u00fcsteemikutsumust mitte kasutada ilma \u00e4\u00e4rmise vajaduseta.<\/p>\n

S\u00fcsteemikutsumised, mis aitavad tagada andmete p\u00fcsivuse<\/h2>\n

\nOlen j\u00f5udnud j\u00e4reldusele, et andmete p\u00fcsivaks salvestamiseks m\u00f5eldud sisendi\/v\u00e4ljundi toiminguteks on olemas kolm l\u00e4henemist. K\u00f5ik need n\u00f5uavad funktsiooni v\u00e4ljakutset fsync()<\/code> kausta, kus fail on loodud. Need l\u00e4henemised on:<\/p>\n

    \n
  1. Funktsiooni v\u00e4ljakutse fdatasync()<\/code> v\u00f5i fsync()<\/code> p\u00e4rast funktsiooni write()<\/code> (on parem kasutada fdatasync()<\/code>).<\/li>\n
  2. Faili descriptoriga t\u00f6\u00f6tamine, mis on avatud lipuga O_DSYNC<\/code> v\u00f5i O_SYNC<\/code> (on parem \u2014 lipuga O_DSYNC<\/code>).<\/li>\n
  3. K\u00e4su kasutamine pwritev2()<\/code> lipuga RWF_DSYNC<\/code> v\u00f5i RWF_SYNC<\/code> (on eelistatavam \u2014 lipuga RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    J\u00f5udluse m\u00e4rkmed<\/h2>\n

    \nMa ei ole p\u00f5hjalikult m\u00f5\u00f5tnud erinevate l\u00e4henemiste j\u00f5udlust, mida olen uurinud. M\u00e4rgatud kiirusvahed on \u00fcsna v\u00e4ikesed. See t\u00e4hendab, et v\u00f5in eksida ja teistes tingimustes v\u00f5ivad samad asjaolud anda teistsuguseid tulemusi. Esiteks r\u00e4\u00e4gin sellest, mis m\u00f5jutab j\u00f5udlust enam, ja seej\u00e4rel sellest, mis m\u00f5jutab j\u00f5udlust v\u00e4hem.<\/p>\n

      \n
    1. Faili andmete \u00fclekatte t\u00e4itmine on kiirem kui andmete failiga liitmine (j\u00f5udluse kasu v\u00f5ib olla 2-100%). Andmete failiga liitmine n\u00f5uab t\u00e4iendavate muudatuste tegemist faili metaandmetes, isegi p\u00e4rast s\u00fcsteemikutsumist fallocate()<\/code>, kuid selle efekti ulatus v\u00f5ib varieeruda. Soovitan, et parima j\u00f5udluse tagamiseks kutsuda fallocate()<\/code> vajaliku ruumi eelnevalt reserveerimiseks. Seej\u00e4rel tuleb see ruum selgelt nullidega t\u00e4ita ja kutsuda fsync()<\/code>. Nii m\u00e4rgitakse vastavad plokid failis\u00fcsteemis kui 'reserveeritud', mitte kui 'reserveerimata'. See toob kaasa v\u00e4ikese (umbes 2%) j\u00f5udluse paranemise. Lisaks v\u00f5ivad m\u00f5ned kettad esmakordsel plokiga juurdep\u00e4\u00e4sutegemisel t\u00f6\u00f6tada aeglasemalt kui teised. See t\u00e4hendab, et ruumi nullidega t\u00e4itmine v\u00f5ib viia m\u00e4rkimisv\u00e4\u00e4rse (umbes 100%) j\u00f5udluse paranemiseni. Eriti v\u00f5ib see juhtuda ketastega AWS EBS<\/a><\/noindex> (need andmed on mitteametlikud, ma ei suutnud neid kinnitada). Sama kehtib ka salvestuste kohta GCP Persistent Disk<\/a><\/noindex> (see on juba ametlik teave, mis on kinnitatud katsetega). Teised spetsialistid on teinud samasuguseid vaatlusi<\/a><\/noindex>, mis on seotud erinevate ketastega.<\/li>\n
    2. Mida v\u00e4hem on s\u00fcsteemikutsungeid, seda k\u00f5rgem on j\u00f5udlus (kasu v\u00f5ib olla umbes 5%). Tundub, et open()<\/code> lipuga O_DSYNC<\/code> v\u00f5i kutse pwritev2()<\/code> lipuga RWF_SYNC<\/code> kiiremini kutse fdatasync()<\/code>. Kahtlen, et asi on selles, et sellise l\u00e4henemise korral on oluline, et sama \u00fclesande lahendamiseks on vaja teha v\u00e4hem s\u00fcsteemik\u00f5nesid (\u00fcks k\u00f5ne kahe asemel). Kuid j\u00f5udluse erinevus on v\u00e4ga v\u00e4ike, seet\u00f5ttu v\u00f5ite selle t\u00e4helepanuta j\u00e4tta ja kasutada rakenduses seda, mis ei too kaasa selle loogika keerukust.<\/li>\n<\/ol>\n

      \nKui teid huvitab andmete p\u00fcsivuse teema \u2013 siin on m\u00f5ned kasulikud materjalid:<\/p>\n