{"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":"Usaldusv\u00e4\u00e4rne andmete ja failide salvestamine Linuxis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uurides andmete s\u00e4ilitamise usaldusv\u00e4\u00e4rsust pilves\u00fcsteemides, otsustasin end proovile panna ja veenduda, et m\u00f5istan p\u00f5hiasju. Ma alustasin NVMe spetsifikatsiooni lugemisega<\/a><\/noindex> et m\u00f5ista, milliseid garantiisid pakuvad NMVe kettad seoses andmete usaldusv\u00e4\u00e4rse s\u00e4ilitamisega (st garanteerides, et andmed on s\u00fcsteemi rikke korral kergesti k\u00e4ttesaadavad). Minu p\u00f5hij\u00e4reldused olid j\u00e4rgmised: andmeid tuleb pidada kahjustatuks hetkest, kui on antud andmete kirjutamise k\u00e4sk, kuni nende t\u00e4ieliku kirjutamiseni salvestusseadmesse. Kuid enamikus andmete kirjutamise programmides kasutatakse s\u00fcsteemi kutseid t\u00e4iesti rahulikult.<\/p>\n

Selles materjalis uurin Linuxi failide API-de kaudu pakutavaid andmete usaldusv\u00e4\u00e4rse s\u00e4ilitamise mehhanisme. Tundub, et siin peaks k\u00f5ik olema lihtne: programm kutsub v\u00e4lja k\u00e4su write()<\/code>, ja kui selle k\u00e4su t\u00f6\u00f6 on l\u00f5petatud, on andmed usaldusv\u00e4\u00e4rselt salvestatud kettale. Kuid write()<\/code> ainult kopeerib rakenduse andmed tuuma vahem\u00e4llu, mis asub juhuslikus m\u00e4lus. Kettale andmete kirjutamise sundimiseks on vaja kasutada m\u00f5ningaid t\u00e4iendavaid mehhanisme.<\/p>\n

\"Usaldusv\u00e4\u00e4rne<\/a><\/noindex><\/p>\n

Kokkuv\u00f5ttes on see materjal m\u00e4rkmete kogum, mis k\u00e4sitleb, mida olen \u00f5ppinud mind huvitavast teemast. Kui r\u00e4\u00e4kida k\u00f5ige olulisemast v\u00e4ga l\u00fchidalt, siis tuleb andmete usaldusv\u00e4\u00e4rse salvestamise organiseerimiseks kasutada k\u00e4sku fdatasync()<\/code> v\u00f5i avada faile lipuga O_DSYNC<\/code>. Kui olete huvitatud, et teada saada, mis t\u00e4pselt juhtub andmetega programmikoodist kuni ketaseni, vaadake seda<\/a><\/noindex> artiklit.
\n<\/a><\/noindex><\/p>\n

Funktsiooni write() kasutamise omadused<\/h2>\n

\nS\u00fcsteemik\u00f5ne write()<\/code> on m\u00e4\u00e4ratletud standardis IEEE POSIX<\/a><\/noindex> kui katse andmete kirjutamiseks failikirjeldajasse. P\u00e4rast edukat t\u00e4itmist write()<\/code> peavad andmete lugemise operatsioonid tagastama t\u00e4pselt need baitid, mis olid enne kirjutatud, isegi juhul, kui andmetele p\u00e4\u00e4sevad juurde teised protsessid v\u00f5i l\u00f5imud (siin on<\/a><\/noindex> vastav jaotis POSIX standardist). Siit<\/a><\/noindex>, jaotises, mis k\u00e4sitleb voogude suhete loomist tavaliste failitoimetamistega, on m\u00e4rge, mille kohaselt kui iga voog kutsub neid funktsioone, peab iga kutse n\u00e4gema kas k\u00f5iki m\u00e4\u00e4ratud tagaj\u00e4rgi, mis tulenevad teise kutse t\u00e4itmisest, v\u00f5i mitte n\u00e4gema \u00fcldse mingeid tagaj\u00e4rgi. See toetab j\u00e4reldust, et k\u00f5ik sisendi\/v\u00e4ljundi failitoimingud peavad hoidma ressurssi, millega nad t\u00f6\u00f6tavad, lukustatud.<\/p>\n

Kas see t\u00e4hendab, et operatsioon write()<\/code> on atomaarne? Tehnilisest vaatepunktist - jah. Andmete lugemise operatsioonid peavad tagastama kas k\u00f5ik v\u00f5i mitte midagi, mis on kirjutatud kasutades write()<\/code>. Kuid operatsioon write()<\/code>, vastavalt standardile ei pea see tingimata l\u00f5petama, kirjutades kogu, mis on talle ette n\u00e4htud. Tal on lubatud salvestada ainult osa andmetest. N\u00e4iteks v\u00f5ib meil olla kaks voogu, iga\u00fcks neist lisab 1024 baidi faili, mis on kirjeldatud sama failihandleriga. Standardi seisukohalt on vastuv\u00f5etav tulemus, kui iga salvestusoperatsioon suudab faili lisada vaid \u00fche baidi. Need operatsioonid j\u00e4\u00e4vad aatomaarseteks, kuid p\u00e4rast nende l\u00f5petamist on failis salvestatud andmed omavahel segamini. Siin on<\/a><\/noindex> selle teema kohta on v\u00e4ga huvitav arutelu Stack Overflow's.<\/p>\n

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

\nLihtsaim viis andmete diskile kirjutamiseks on funktsiooni v\u00e4ljakutse fsync()<\/a><\/noindex>. See funktsioon palub operatsioonis\u00fcsteemil viia k\u00f5ik muudetud plokid vahem\u00e4lust diskile. See h\u00f5lmab ka k\u00f5iki failide metaandmeid (juurdep\u00e4\u00e4su aeg, faili muutmise aeg jne). Arvan, et nende metaandmete vajadus tekib harva, seega kui teate, et need ei ole teie jaoks olulised, v\u00f5ite kasutada funktsiooni fdatasync()<\/code>. Dokumendihalduses abi<\/a><\/noindex> kohta fdatasync()<\/code> On v\u00e4idetud, et selle funktsiooni t\u00f6\u00f6tamise k\u00e4igus salvestatakse kettale sellises mahus metaandmeid, mis on vajalik j\u00e4rgmiste andmelugemise toimingute \u00f5igeaegseks t\u00e4itmiseks. See on just see, mis enamikku rakendusi huvitab.<\/p>\n

\u00dcks probleem, mis siin v\u00f5ib tekkida, on see, et need mehhanismid ei garanteeri, et faili saab p\u00e4rast v\u00f5imalikke t\u00f5rkeid leida. Eriti siis, kui luuakse uus fail, tuleb kutsuda fsync()<\/code> kausta, mis seda sisaldab. Vastasel juhul v\u00f5ib p\u00e4rast t\u00f5rget selguda, et see fail ei eksisteeri. Selle p\u00f5hjuseks on see, et UNIXis, j\u00e4igade linkide kasutamise t\u00f5ttu, v\u00f5ib fail eksisteerida mitmes kaustas. Seet\u00f5ttu kutsudes fsync()<\/code> faili puhul ei ole v\u00f5imalik teada saada, millise kausta andmeid tuleb samuti kettale salvestada (siin<\/a><\/noindex> selle kohta saab lugeda rohkem). Tundub, et failis\u00fcsteem ext4 on suuteline automaatselt<\/a><\/noindex> rakendama fsync()<\/code> kaustadele, mis sisaldavad vastavaid faile, kuid teiste failis\u00fcsteemide puhul ei pruugi see nii olla.<\/p>\n

See mehhanismi rakendamine v\u00f5ib erinevates failis\u00fcsteemides erineda. Kasutasin blktrace<\/a><\/noindex> , et teada saada, milliseid kettaoperatsioone kasutatakse failis\u00fcsteemides ext4 ja XFS. M\u00f5lemad v\u00e4ljastavad tavap\u00e4rased ketta kirjutamise k\u00e4sud, nii failisisu osas kui ka failis\u00fcsteemi logis, t\u00fchjendavad vahem\u00e4lu ja l\u00f5petavad t\u00f6\u00f6, tehes FUA-kirjutuse (Force Unit Access, andmete kirjutamine otse kettale, m\u00f6\u00f6da vahem\u00e4lu) logisse. T\u00f5en\u00e4oliselt k\u00e4ituvad nad nii operatsiooni kinnitamise tagamiseks. Ketastel, mis ei toeta FUA-d, p\u00f5hjustab see kahe vahem\u00e4lu t\u00fchjendamise. Minu katsed on n\u00e4idanud, et fdatasync()<\/code> veidi kiiremini fsync()<\/code>. T\u00f6\u00f6riist blktrace<\/code> n\u00e4itab, et fdatasync()<\/code> tavaliselt kirjutab 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 abil blktrace<\/code> sain teada, et fdatasync()<\/code> t\u00fchjendab kettale v\u00e4hem andmeid (4 KiB XFS).<\/p>\n

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

\nM\u00e4letan kolme kahtlast olukorda, millega olen praktikas silmitsi seisnud. fsync()<\/code>, millega ma praktikas kokku puutusin.<\/p>\n

Esimene selline juhtum leidis aset 2008. aastal. Sel ajal 'riputas' Firefox 3 liides, kui salvestati suure arvu failide andmeid kettale. Probleem oli seotud sellega, et liidese olekuandmete talletamiseks kasutati SQLite andmebaasi. Iga kord, kui liideses toimus muutus, kutsuti v\u00e4lja funktsioon fsync()<\/code>, mis pakkus head garantiid andmete stabiilse salvestamise kohta. Toona kasutusel olnud ext3 failis\u00fcsteemis funktsioon fsync()<\/code> salvestas kettale k\u00f5ik 'm\u00e4danenud' lehed s\u00fcsteemis, mitte ainult need, mis olid seotud vastava failiga. See t\u00e4hendas, et Firefoxi nuppudele kl\u00f5psamine v\u00f5is alustada megabaitide andmete salvestamist magnetkettale, mis v\u00f5is kesta mitu sekundit. Probleemi lahendus, nii nagu ma aru sain sellest<\/a><\/noindex> materjalist, seisnes andmebaasiga t\u00f6\u00f6tamise \u00fcleviimises as\u00fcnkroonsetesse taustategevustesse. See t\u00e4hendab, et varem rakendati Firefoxis rangemaid n\u00f5udeid andmete stabiilse salvestamise osas, kui see reaalselt vajalik oli, ja ext3 failis\u00fcsteemi erip\u00e4ra s\u00fcvendas seda probleemi.<\/p>\n

Teine probleem tekkis 2009. aastal. P\u00e4rast s\u00fcsteemi riket sattusid uue ext4 failis\u00fcsteemi kasutajad olukorda, kus paljud hiljuti loodud failid olid nullpikkusega, samas kui vanema ext3 failis\u00fcsteemi puhul seda ei juhtunud. Eelnevas l\u00f5igus r\u00e4\u00e4kisin, et ext3 salvestas kettale liiga palju andmeid, mis aeglustas t\u00f6\u00f6d m\u00e4rkimisv\u00e4\u00e4rselt. fsync()<\/code>Selle olukorra parandamiseks salvestatakse ext4 failile kettale vaid need 'mustad' lehek\u00fcljed, mis on seotud konkreetse failiga. \u00dclej\u00e4\u00e4nud failide andmed j\u00e4\u00e4vad m\u00e4llu palju pikemaks ajaks kui ext3 kasutamisel. See tehti j\u00f5udluse parandamise nimel (vaikimisi j\u00e4\u00e4vad andmed sellesse olekusse 30 sekundiks, seda saab seadistada koos dirty_expire_centisecs<\/a><\/noindex>; siin<\/a><\/noindex> leiate t\u00e4iendavaid materjale selle kohta). See t\u00e4hendab, et suur hulk andmeid v\u00f5ib p\u00e4rast rikete tekkimist p\u00f6\u00f6rdumatult kaduma minna. Selle probleemi lahenduseks on fsync()<\/code> rakendustes, mis peavad tagama andmete stabiilse s\u00e4ilitamise ja maksimaalselt nende kaitsmise rikete tagaj\u00e4rgede eest. Funktsioon fsync()<\/code> ext4 t\u00f6\u00f6tab m\u00e4rksa t\u00f5husamalt kui ext3. Selle l\u00e4henemise miinus on aga see, et selle kasutamine aeglustab teatud toimingute, n\u00e4iteks programmide installimise, teostamist. Lisainfot leiate siit siit<\/a><\/noindex> ja siit<\/a><\/noindex>.<\/p>\n

Kolmas probleem, mis puudutab fsync()<\/code>, tekkis 2018. aastal. Siis selgus PostgreSQL projekti raames, et kui funktsioon fsync()<\/code> kohtub veaga, m\u00e4rgib ta 'mustad' lehed kui 'puhtad'. Selle tulemusena ei tehta j\u00e4rgmiste k\u00f5nede fsync()<\/code> selliste lehtedega midagi. Selle t\u00f5ttu j\u00e4\u00e4vad muudetud lehed m\u00e4llu ja neid ei kirjutata kunagi kettale. See on t\u00f5eline katastroof, kuna rakendus arvab, et andmed on kettale kirjutatud, kuid tegelikult see nii ei ole. Sellised t\u00f5rked fsync()<\/code> on haruldased, rakendus ei suuda sellistes olukordades peaaegu midagi teha probleemi lahendamiseks. T\u00e4nap\u00e4eval, kui see juhtub, PostgreSQL ja teised rakendused l\u00f5petavad \u00e4kki t\u00f6\u00f6. Siit<\/a><\/noindex>, artiklis 'Kas rakendused saavad fsync t\u00f5rgetest taastuda?', uuritakse seda probleemi k\u00f5igis detailides. Praegu on parim lahendus selle probleemi lahendamiseks Direct I\/O kasutamine koos lipuga O_SYNC<\/code> v\u00f5i lipuga O_DSYNC<\/code>. Selle l\u00e4henemise korral teatab s\u00fcsteem vigadest, mis v\u00f5ivad tekkida konkreetsete andmete kirjutamise toimingute k\u00e4igus, kuid see n\u00f5uab, et rakendus haldaks puhverdusi ise. Lisateavet leiate siit siit<\/a><\/noindex> ja siit<\/a><\/noindex>.<\/p>\n

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

\nNaaseme arutelule Linuxi mehhanismide \u00fcle, mis tagavad andmete j\u00e4rjepideva salvestamise. Eelk\u00f5ige r\u00e4\u00e4gime me lipu kasutamisest O_SYNC<\/code> v\u00f5i lipust O_DSYNC<\/code> failide avamisel s\u00fcsteemik\u00f5ne kaudu open()<\/a><\/noindex>. Selle l\u00e4henemisega viiakse iga andme kirjutamise toiming l\u00e4bi nagu p\u00e4rast iga k\u00e4sku antaks s\u00fcsteemile vastavad k\u00e4sud write()<\/code> POSIX spetsifikatsioonide fsync()<\/code> ja fdatasync()<\/code>. Dokumendihalduses seda nimetatakse \u201eS\u00fcnkroonitud I\/O Faili Terviklikkuse T\u00e4itmine\u201c ja \u201eAndmete Terviklikkuse T\u00e4itmine\u201c. Selle l\u00e4henemise peamine eelis on see, et andmete terviklikkuse tagamiseks tuleb teha vaid \u00fcks s\u00fcsteemik\u00f5ne, mitte kaks (n\u00e4iteks \u2014<\/a><\/noindex> ). Selle l\u00e4henemise peamine puudus on see, et k\u00f5ik kirjutamisoperatsioonid, mis kasutavad vastavat failide kirjeldajat, synchroniseeritakse, mis v\u00f5ib piirata rakenduse koodi struktureerimise v\u00f5imalusi. write()<\/code> ja fdatasync()<\/code>). Selle l\u00e4henemise peamine puudus on see, et k\u00f5ik kirjutamise operatsioonid, mis kasutavad vastavat faili deskriptorit, saavad olema s\u00fcnkroniseeritud, mis v\u00f5ib piirata rakenduse koodistruktuuri loomise v\u00f5imalusi.<\/p>\n

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

\nS\u00fcsteemik\u00f5ne open()<\/code> toetab lippu O_DIRECT<\/code>, mis on m\u00f5eldud selleks, et v\u00e4ltida operatsioonis\u00fcsteemi vahem\u00e4lu, teostades sisendi-v\u00e4ljundi toiminguid otse kettaga. See t\u00e4hendab, et paljusid juhtumeid, kirjutamisk\u00e4sklusi, mis on antud programmile, edastatakse otse kettale suunatud k\u00e4sklusteks. Kuid \u00fcldiselt ei asenda see mehhanism funktsioone fsync()<\/code> v\u00f5i fdatasync()<\/code>. Asi on selles, et ise ketas v\u00f5ib edasi l\u00fckata v\u00f5i vahem\u00e4luda<\/a><\/noindex> vastavaid andmete kirjutamise k\u00e4ske. Ja mis veelgi hullem, m\u00f5ningatel erijuhtudel, sisendi-v\u00e4ljundi toimingud, mis teostatakse lippu kasutades O_DIRECT<\/code>, t\u00f5lgitakse<\/a><\/noindex> traditsioonilisteks puhverdatud toiminguteks. Selle probleemi lahendamine on lihtsaim viis avada failid ka lipuga O_DSYNC<\/code>, mis t\u00e4hendab, et iga kirjutamistoiminguga kaasneb kutse fdatasync()<\/code>.<\/p>\n

Leiti, et failis\u00fcsteemis XFS on hiljuti lisatud \"kiire tee\" O_DIRECT|O_DSYNC<\/code>-andmete kirjutamiseks. Kui kirjutatakse \u00fcle plokk, kasutades O_DIRECT|O_DSYNC<\/code>, siis XFS, asemel vahem\u00e4lu t\u00fchjendamise, t\u00e4idab FUA-kirje k\u00e4sku, kui seade seda toetab. Olen selle kinnitanud t\u00f6\u00f6riista kasutamisega blktrace<\/code> Linuxi s\u00fcsteemis 5.4\/Ubuntu 20.04. See l\u00e4henemine peaks olema efektiivsem, kuna selle kasutamisel kirjutatakse kettale minimaalne kogus andmeid ja kasutatakse \u00fchte toimingut, mitte kahte (kirjutamine ja vahem\u00e4lu t\u00fchjendamine). Leidsin viite plekk<\/a><\/noindex> 2018. aasta tuuma, kus see mehhanism on rakendatud. Seal on arutelu, mis k\u00e4sitleb selle optimeerimise rakendamist ka teistes failis\u00fcsteemides, kuid niipalju kui mina tean, on XFS praegu ainus failis\u00fcsteem, mis seda toetab.<\/p>\n

sync_file_range()<\/h2>\n

\nLinuxis on s\u00fcsteemi k\u00f5ne sync_file_range()<\/a><\/noindex>, mis v\u00f5imaldab kirjutada kettale ainult osa failist, mitte kogu faili. See k\u00f5ne algatab as\u00fcnkroonse andmete kirjutamise ja ei oota selle l\u00f5petamist. Kuid juhendis sync_file_range()<\/code> \u00f6eldakse, et k\u00e4sk on \"v\u00e4ga ohtlik\". Selle kasutamine ei ole soovitatav. Erip\u00e4ra ja ohtlikud aspektid sync_file_range()<\/code> on v\u00e4ga h\u00e4sti kirjeldatud selles<\/a><\/noindex> materjalis. Eriti paistab silma, et see kutse kasutab RocksDB-d selleks, et hallata, millal s\u00fcdamik \"r\u00e4pane\" teave kettale kirjutab. Kuid selleks, et andmed oleksid stabiilselt salvestatud, kasutatakse ka fdatasync()<\/code>. Dokumendihalduses koodis<\/a><\/noindex> RocksDB-s on selle teema kohta huvitavad kommentaarid. N\u00e4iteks tundub, et kutse sync_file_range()<\/code> ZFS-i kasutamisel ei p\u00f5hjusta andmete kirjutamist kettale. Minu kogemus \u00fctleb, et harva kasutatav kood v\u00f5ib sisaldada vigu. Seet\u00f5ttu soovitaksin seda s\u00fcsteemikutsumist v\u00e4ltida, kui see ei ole h\u00e4davajalik.<\/p>\n

S\u00fcsteemikutsed, mis aitavad tagada andmete stabiilse salvestamise<\/h2>\n

\nJ\u00f5udsin j\u00e4reldusele, et andmete stabiilse salvestamise tagamiseks saab kasutada kolme l\u00e4henemisviisi. K\u00f5ik need n\u00f5uavad funktsiooni v\u00e4ljakutset fsync()<\/code> kaustas, kus fail on loodud. Siin on need l\u00e4henemisviisid:<\/p>\n

    \n
  1. Funktsiooni v\u00e4ljakutse fdatasync()<\/code> v\u00f5i fsync()<\/code> p\u00e4rast funktsiooni write()<\/code> (soovitatav on kasutada fdatasync()<\/code>).<\/li>\n
  2. Failideskirpti kasutamine, mis on avatud lipuga O_DSYNC<\/code> v\u00f5i O_SYNC<\/code> (parem \u2014 lipuga O_DSYNC<\/code>).<\/li>\n
  3. K\u00e4skluse kasutamine pwritev2()<\/code> lipu RWF_DSYNC<\/code> v\u00f5i RWF_SYNC<\/code> (eelistatult \u2014 lipuga RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Toimivuse m\u00e4rkmed<\/h2>\n

    \nMa ei ole teadlikult m\u00f5\u00f5tnud erinevate uuritud mehhanismide j\u00f5udlust. Minu t\u00e4hele pandud kiiruseread on \u00fcsna v\u00e4iksed. See t\u00e4hendab, et ma v\u00f5in eksida ja et samade tingimuste korral v\u00f5ivad tulemused olla erinevad. Esiteks r\u00e4\u00e4gin sellest, mis m\u00f5jutab j\u00f5udlust k\u00f5ige enam, ja seej\u00e4rel, mis m\u00f5jutab j\u00f5udlust v\u00e4hem.<\/p>\n

      \n
    1. Faili andmete \u00fcle kirjutamine on kiirem kui andmete lisamine failile (j\u00f5udluse kasum v\u00f5ib ulatuda 2\u2013100%). Failile andmete lisamine n\u00f5uab lisamuudatusi faili metaandmetes, isegi p\u00e4rast s\u00fcsteemik\u00f5net, fallocate()<\/code>, kuid selle efekti ulatus v\u00f5ib varieeruda. Soovitan parima j\u00f5udluse tagamiseks kutsuda fallocate()<\/code> v\u00e4lja vajaliku ruumi eelnevalt eraldamiseks. Siis tuleb see ruum selges\u00f5naliselt nullidega t\u00e4ita ja kutsuda fsync()<\/code>. T\u00e4nu sellele m\u00e4rgistatakse vastavad plokid failis\u00fcsteemis kui \"valitud\", mitte kui \"mittevalitud\". See toob kaasa v\u00e4ikese (umbes 2%) j\u00f5udluse paranemise. Lisaks sellele v\u00f5ivad m\u00f5ned kettad esimesel ploki ligip\u00e4\u00e4su operatsioonil olla aeglasemad kui teised. See t\u00e4hendab, et ruumi t\u00e4itmine nullidega v\u00f5ib tuua kaasa m\u00e4rkimisv\u00e4\u00e4rse (umbes 100%) j\u00f5udluse paranemise. Eelk\u00f5ige v\u00f5ib see juhtuda ketastega AWS EBS<\/a><\/noindex> (need on mitteformaalne andmed, neid ei ole v\u00f5imalik kinnitada). Sama kehtib ka salvestuste kohta. GCP Persistent Disk<\/a><\/noindex> (see on juba ametlik teave, kinnitatud katsetega). Teised spetsialistid on teinud sarnaseid t\u00e4heldusi<\/a><\/noindex>, mis on seotud erinevate ketastega.<\/li>\n
    2. Mida v\u00e4hem on s\u00fcsteemik\u00f5nesid, seda k\u00f5rgem on j\u00f5udlus (kasv v\u00f5ib olla umbes 5%). Tundub, et k\u00f5ne open()<\/code> lipu O_DSYNC<\/code> v\u00f5i k\u00f5ne pwritev2()<\/code> lipu RWF_SYNC<\/code> on kiiremini kui k\u00f5ne fdatasync()<\/code>Kahtlen, et asi on selles, et sellise l\u00e4henemise puhul m\u00e4ngib rolli, et \u00fche ja sama \u00fclesande t\u00e4itmiseks tuleb teha v\u00e4hem s\u00fcsteemi k\u00f5nesid (\u00fcks k\u00f5ne kahe asemel). Kuid j\u00f5udluse erinevus on v\u00e4ga v\u00e4ike, seega v\u00f5ite selle t\u00e4iesti t\u00e4helepanuta j\u00e4tta ja kasutada rakenduses seda, mis ei too kaasa selle loogika keerukuse suurenemist.<\/li>\n<\/ol>\n

      \nKui teid huvitab andmete usaldusv\u00e4\u00e4rne salvestamine, siis siin on m\u00f5ned kasulikud materjalid:<\/p>\n