{"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\/hr\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Odr\u017eivo pohranjivanje podataka i Linux API-ji za datoteke","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Istra\u017euju\u0107i odr\u017eivost pohrane podataka u oblaku, odlu\u010dio sam provjeriti svoje znanje i uvjeriti se da razumijem osnovne stvari. Ja po\u010deo sam s \u010ditanjem specifikacije NVMe<\/a><\/noindex> kako bih razumio koje nam garancije vezane za odr\u017eivu pohranu podataka (tj. garancije da \u0107e podaci biti dostupni nakon sustavnog kvara) pru\u017eaju NMVe diskovi. Moji glavni zaklju\u010dci su sljede\u0107i: podaci se moraju smatrati o\u0161te\u0107enima od trenutka kada se izdaje naredba za zapis podataka, do trenutka kada zavr\u0161i zapis na medij. Me\u0111utim, u ve\u0107ini programa za zapis podataka, sustavni pozivi se koriste bez problema.<\/p>\n

U ovom materijalu ispitat \u0107u mehanizme odr\u017eive pohrane podataka koje pru\u017eaju Linuxove datote\u010dne API-je. \u010cini se da bi to ovdje trebalo biti jednostavno: program izvr\u0161ava naredbu write()<\/code>, a nakon zavr\u0161etka rada te naredbe, podaci \u0107e biti pouzdano pohranjeni na disku. No write()<\/code> samo kopira podatke aplikacije u ke\u0161 jezgre smje\u0161ten u radnoj memoriji. Da bi se prisilila sustav na zapis podataka na disk, potrebno je koristiti neke dodatne mehanizme.<\/p>\n

\"Odr\u017eivo<\/a><\/noindex><\/p>\n

U cjelini, ovaj materijal predstavlja skup bilje\u0161ki o tome \u0161to sam saznao o temi koja me zanima. Ako bih vrlo kratko rekao najva\u017enije, to bi bilo da za organizaciju odr\u017eive pohrane podataka treba koristiti naredbu fdatasync()<\/code> ili otvoriti datoteke s oznakom O_DSYNC<\/code>. Ako vas zanima \u0161to se doga\u0111a s podacima na putu od programskog koda do diska, pogledajte ovu<\/a><\/noindex> \u010dlanak.
\n<\/a><\/noindex><\/p>\n

Osobitosti kori\u0161tenja funkcije write()<\/h2>\n

\nSistem poziv write()<\/code> definiran je u standardu IEEE POSIX<\/a><\/noindex> kao poku\u0161aj zapisivanja podataka u datote\u010dni deskriptor. Nakon uspje\u0161nog zavr\u0161etka write()<\/code> operacije \u010ditanja podaci moraju vra\u0107ati upravo one bajtove koji su prethodno zapisani, \u010dine\u0107i to \u010dak i kada se podacima pristupa iz drugih procesa ili niti (evo<\/a><\/noindex> odgovaraju\u0107i dio standarda POSIX). Ovdje<\/a><\/noindex>, u odjeljku posve\u0107enom interakciji tokova s obi\u010dnim datote\u010dnim operacijama, postoji napomena koja ka\u017ee da ako svaki od dva toka poziva te funkcije, svaki poziv treba vidjeti ili sve ozna\u010dene posljedice koje proizlaze iz izvr\u0161enja drugog poziva, ili ne vidjeti nikakve posljedice. To omogu\u0107uje zaklju\u010dak da sve datote\u010dne operacije ulaza\/izlaza moraju zadr\u017eati zaklju\u010davanje resursa s kojim rade.<\/p>\n

Zna\u010di li to da je operacija write()<\/code> atomarna? Tehni\u010dki gledano \u2014 da. Operacije \u010ditanja podataka trebaju vra\u0107ati ili sve, ili ni\u0161ta od onoga \u0161to je zapisano pomo\u0107u write()<\/code>. No, operacija write()<\/code>, prema standardu, ne mora nu\u017eno zavr\u0161iti zapisivanjem svega \u0161to je bila odobrena za zapisivanje. Dozvoljeno joj je zapisati samo dio podataka. Na primjer, mo\u017eemo imati dva toka, svaki od kojih pridru\u017euje 1024 bajta datoteci koja se opisuje istim deskriptorom datoteke. Iz perspektive standarda, rezultat u kojem svaka od operacija zapisivanja mo\u017ee pridru\u017eiti samo jedan bajt datoteci bit \u0107e prihvatljiv. Ove operacije ostat \u0107e atomske, ali nakon \u0161to zavr\u0161e, podaci koje su zapisali u datoteku bit \u0107e pomije\u0161ani. Evo<\/a><\/noindex> vrlo zanimljiva rasprava na ovu temu na Stack Overflow-u.<\/p>\n

Funkcije fsync() i fdatasync()<\/h2>\n

\nNajjednostavniji na\u010din za isklju\u010divanje podataka na disk je pozivanje funkcije fsync()<\/a><\/noindex>. Ova funkcija tra\u017ei od operativnog sustava da prenese sve modificirane blokove iz predmemorije na disk. To uklju\u010duje i sve metapodatke datoteke (vrijeme pristupa, vrijeme modifikacije datoteke itd.). Smatram da je potreba za tim metapodacima rijetka, stoga, ako znate da vam nisu va\u017eni, mo\u017eete koristiti funkciju fdatasync()<\/code>. U pomo\u0107<\/a><\/noindex> o fdatasync()<\/code> navodi da tijekom rada ove funkcije dolazi do spremanja na disk tog volumena metapodataka koji je \u201eneophodan za pravilno izvr\u0161avanje sljede\u0107ih operacija \u010ditanja podataka\u201d. A to je ono \u0161to brine ve\u0107inu aplikacija.<\/p>\n

Jedan od problema koji ovdje mo\u017ee nastati jest to \u0161to ti mehanizmi ne jam\u010de da \u0107e datoteka biti otkrivena nakon mogu\u0107eg kvara. Konkretno, kada se stvara nova datoteka, potrebno je pozvati fsync()<\/code> za direktorij, koji ga sadr\u017ei. Ina\u010de, nakon kvara mo\u017ee se dogoditi da ovaj datoteka ne postoji. Razlog za to je \u0161to u UNIX-u, zbog kori\u0161tenja tvrdih veza, datoteka mo\u017ee postojati u vi\u0161e direktorija. Stoga prilikom pozivanja fsync()<\/code> za datoteku nema na\u010dina da sazna koja to\u010dno direktorija tako\u0111er treba zapisati na disk (ovdje<\/a><\/noindex> o tome se mo\u017ee pro\u010ditati detaljnije). \u010cini se da datote\u010dni sustav ext4 mo\u017ee automatski<\/a><\/noindex> se primjenjivati fsync()<\/code> do direktorija koji sadr\u017ee odgovaraju\u0107e datoteke, ali u slu\u010daju drugih datote\u010dnih sustava to mo\u017eda nije tako.<\/p>\n

Omekanik mo\u017ee biti razli\u010dito implementiran u razli\u010ditim datote\u010dnim sustavima. Koristio sam blktrace<\/a><\/noindex> da saznam koje diskovne operacije se koriste u datote\u010dnim sustavima ext4 i XFS. I jedan i drugi daju uobi\u010dajene naredbe za zapis na disk i za sadr\u017eaj datoteka, i za dnevnik datote\u010dnog sustava, ispu\u0161taju ke\u0161 i zavr\u0161avaju rad, izvr\u0161avaju\u0107i FUA-zapis (Force Unit Access, zapis podataka izravno na disk, mimo ke\u0161a) u dnevnik. Vjerojatno to \u010dine kako bi potvrdili \u010dinjenicu da se operacija dogodila. Na diskovima koji ne podr\u017eavaju FUA, to uzrokuje dva ispisa ke\u0161a. Moji eksperimenti su pokazali da fdatasync()<\/code> malo br\u017ee fsync()<\/code>. Alat blktrace<\/code> ukazuje na to da fdatasync()<\/code> obi\u010dno pi\u0161e manje podataka na disk (u ext4 fsync()<\/code> zapisuje 20 KiB, a fdatasync()<\/code> \u2014 16 KiB). Osim toga, otkrio sam da je XFS malo br\u017ei od ext4. A ovdje je uz pomo\u0107 blktrace<\/code> uspjelo saznati da fdatasync()<\/code> ispisuje manje podataka na disk (4 KiB u XFS).<\/p>\n

Nejasne situacije koje nastaju prilikom kori\u0161tenja fsync()<\/h2>\n

\nMogu se sjetiti tri nejasne situacije koje se odnose fsync()<\/code>, s kojima sam se susreo u praksi.<\/p>\n

Prvi takav slu\u010daj dogodio se 2008. godine. Tada je su\u010delje Firefox 3 \u201ezalegalo\u201c ako se izvo\u0111ena zapisa na disk velikog broja datoteka. Problem je bila u tome \u0161to se u implementaciji su\u010delja za pohranu informacija o njegovom stanju koristila baza podataka SQLite. Nakon svake promjene koja se dogodila u su\u010delju, pozivala se funkcija fsync()<\/code>, \u0161to je davalo dobra jamstva trajnog pohranjivanja podataka. U tada kori\u0161tenom datote\u010dnom sustavu ext3 funkcija fsync()<\/code> spremala je na disk sve \"prljave\" stranice u sustavu, a ne samo one koje su se odnosile na odre\u0111enu datoteku. To je zna\u010dilo da je klik na gumb u Firefoxu mogao inicirati zapis megabajta podataka na magnetski disk, \u0161to je moglo potrajati i nekoliko sekundi. Rje\u0161enju problema, koliko sam shvatio iz ovoga<\/a><\/noindex> materijala, bilo je potrebno premjestiti rad s bazom podataka u asinkrone pozadinske zadatke. To zna\u010di da su u Firefoxu prije bili implementirani rigorozniji zahtjevi za otpornost pohrane podataka nego \u0161to je to stvarno bilo potrebno, a osobine sustava datoteka ext3 su samo pogor\u0161ale ovaj problem.<\/p>\n

Druga neuskla\u0111enost dogodila se 2009. godine. Tada su, nakon kvara sustava, korisnici nove datote\u010dne sustave ext4 nai\u0161li na to da mnoge nedavno stvorene datoteke imaju nulu du\u017einu, a s starijom datote\u010dnom sustavom ext3 to se nije dogodilo. U prethodnom odlomku govorio sam o tome da je ext3 na disk isporu\u010divala previ\u0161e podataka, \u0161to je znatno usporilo rad fsync()<\/code>. Da bi se pobolj\u0161ala situacija, ext4 na disk isporu\u010duje samo one \"prljave\" stranice koje su vezane uz odre\u0111enu datoteku. A podaci drugih datoteka ostaju u memoriji znatno du\u017ee nego kod primjene ext3. Ovo je u\u010dinjeno radi pobolj\u0161anja performansi (po defaultu, podaci ostaju u tom stanju 30 sekundi, to se mo\u017ee podesiti uz pomo\u0107 dirty_expire_centisecs<\/a><\/noindex>; ovdje<\/a><\/noindex> mo\u017eete prona\u0107i dodatne materijale o tome). To zna\u010di da se veliki volumen podataka mo\u017ee trajno izgubiti nakon kvara. Rje\u0161enje ovog problema le\u017ei u kori\u0161tenju fsync()<\/code> u aplikacijama koje trebaju osigurati otpornu pohranu podataka i maksimalno ih za\u0161tititi od posljedica kvarova. Funkcija fsync()<\/code> djeluje pri kori\u0161tenju ext4 mnogo u\u010dinkovitije nego pri kori\u0161tenju ext3. Minus ovog pristupa je da njegovo kori\u0161tenje, kao i prije, usporava izvr\u0161enje nekih operacija, poput instalacije programa. Pojedinosti o tome pogledajte ovdje<\/a><\/noindex> i ovdje<\/a><\/noindex>.<\/p>\n

Tre\u0107i problem, koji se odnosi na fsync()<\/code>, dogodio se 2018. godine. Tada, u okviru projekta PostgreSQL, otkriveno je da ako funkcija fsync()<\/code> naleti na pogre\u0161ku, ozna\u010dava \"prljave\" stranice kao \"\u010diste\". Kao rezultat toga, sljede\u0107i pozivi fsync()<\/code> ni\u0161ta se ne radi s takvim stranicama. Zbog toga modificirane stranice ostaju u memoriji i nikada se ne zapisuju na disk. To je prava katastrofa, jer \u0107e aplikacija smatrati da su neki podaci zapisani na disku, dok to zapravo ne\u0107e biti tako. Takvi kvarovi fsync()<\/code> javljaju se rijetko, aplikacija u takvim situacijama gotovo ni\u0161ta ne mo\u017ee u\u010diniti za borbu protiv problema. Danas, kada se to dogodi, PostgreSQL i druge aplikacije naglo zavr\u0161avaju s radom. Ovdje<\/a><\/noindex>, u materijalu \u201eMogu li aplikacije oporaviti se od fsync kvarova?\u201c, ovaj problem se istra\u017euje u svim detaljima. Trenutno je najbolje rje\u0161enje za ovaj problem kori\u0161tenje Direct I\/O s oznakom O_SYNC<\/code> ili s oznakom O_DSYNC<\/code>. Takvim pristupom sustav \u0107e prijaviti gre\u0161ke koje se mogu pojaviti tijekom izvr\u0161avanja odre\u0111enih operacija zapisivanja podataka, ali ovaj pristup zahtijeva da aplikacija samostalno upravlja memorijskim bufferima. Vi\u0161e detalja o tome mo\u017eete pro\u010ditati ovdje<\/a><\/noindex> i ovdje<\/a><\/noindex>.<\/p>\n

Otvaranje datoteka s oznakama O_SYNC i O_DSYNC<\/h2>\n

\nVratimo se raspravi o mehanizmima Linuxa koji osiguravaju pouzdano pohranjivanje podataka. Naime, rije\u010d je o upotrebi oznake O_SYNC<\/code> ili oznake O_DSYNC<\/code> prilikom otvaranja datoteka koriste\u0107i sistemski poziv open()<\/a><\/noindex>. Takvim pristupom, svaka operacija zapisivanja podataka izvr\u0161ava se tako kao da sustav dobiva, prema tome, naredbe write()<\/code> sustavu daju, odnosno, naredbe fsync()<\/code> i fdatasync()<\/code>. U specifikaciji POSIX<\/a><\/noindex> to se naziva \u201eSinhronizirano I\/O zavr\u0161ava cjelovitost datoteke\u201c i \u201eZavr\u0161etak cjelovitosti podataka\u201c. Glavna prednost ovog pristupa je u tome \u0161to je za osiguranje cjelovitosti podataka potreban samo jedan sistemski poziv, a ne dva (na primjer \u2014 write()<\/code> i fdatasync()<\/code>). Glavni nedostatak ovog pristupa je taj \u0161to \u0107e sve operacije zapisivanja koje koriste odgovaraju\u0107i deskriptor datoteke biti sinkronizirane, \u0161to mo\u017ee ograni\u010diti mogu\u0107nosti strukturiranja koda aplikacije.<\/p>\n

Kori\u0161tenje Direct I\/O s oznakom O_DIRECT<\/h2>\n

\nSistem poziv open()<\/code> podr\u017eava oznaku O_DIRECT<\/code>, koja je namijenjena za to da, zaobi\u0161av\u0161i cache operativnog sustava, izvr\u0161ava operacije ulaz\/izlaz, direktno komuniciraju\u0107i s diskom. To, u mnogim slu\u010dajevima, zna\u010di da \u0107e naredbe zapisivanja koje izdaje program biti direktno prenesene u naredbe usmjerene na rad s diskom. No, op\u0107enito, ovaj mehanizam nije zamjena za funkcije fsync()<\/code> ili fdatasync()<\/code>. Naime, sam disk mo\u017ee odlo\u017eiti ili ke\u0161irati<\/a><\/noindex> odgovaraju\u0107e komande za zapis podataka. I, \u0161to je jo\u0161 gore, u nekim posebnim slu\u010dajevima operacije ulaza-izlaza izvr\u0161ene upotrebom oznake O_DIRECT<\/code>, se prenose<\/a><\/noindex> na tradicionalne buferizirane operacije. Najlak\u0161e je rije\u0161iti ovaj problem koriste\u0107i za otvaranje datoteka i oznaku O_DSYNC<\/code>, \u0161to \u0107e zna\u010diti da za svaku operaciju zapisivanja slijedi poziv fdatasync()<\/code>.<\/p>\n

Ispostavilo se da je u datote\u010dnom sustavu XFS nedavno dodan \u201ebrzi put\u201c za O_DIRECT|O_DSYNC<\/code>-zapis podataka. Ako se prepisuje blok koriste\u0107i O_DIRECT|O_DSYNC<\/code>, tada XFS, umjesto da isprazni ke\u0161, izvr\u0161it \u0107e FUA-zapisnu naredbu u slu\u010daju da ure\u0111aj to podr\u017eava. To sam potvrdio koriste\u0107i alat blktrace<\/code> u sustavu Linux 5.4\/Ubuntu 20.04. Ovaj pristup trebao bi biti u\u010dinkovitiji, jer se pri njemu na disk zapisuje minimalna koli\u010dina podataka, a pritom se koristi jedna operacija, a ne dvije (zapis i ispu\u0161tanje ke\u0161a). Prona\u0161ao sam poveznicu na zakrpa<\/a><\/noindex> jezgru iz 2018. godine koja implementira ovaj mehanizam. Tu se raspravlja o primjeni ove optimizacije i u drugim datote\u010dnim sustavima, ali koliko mi je poznato, XFS je trenutno jedini datote\u010dni sustav koji to podr\u017eava.<\/p>\n

Funkcija sync_file_range()<\/h2>\n

\nU Linuxu postoji sistemski poziv sync_file_range()<\/a><\/noindex>, koji omogu\u0107uje ispu\u0161tanje na disk samo dijela datoteke, a ne cijele datoteke. Ovaj poziv pokre\u0107e asinhrono ispu\u0161tanje podataka i ne \u010deka njegovo dovr\u0161avanje. No, u priru\u010dniku za sync_file_range()<\/code> stoji da je ova naredba \u201evrlo opasna\u201c. Preporu\u010duje se da se s njom ne koristi. Karakteristike i opasnosti sync_file_range()<\/code> vrlo su dobro opisane u ovom<\/a><\/noindex> materijalu. Konkretno, o\u010dito, ovaj poziv koristi RocksDB za upravljanje vremenom kada jezgra ispu\u0161ta \u201eprljave\u201c podatke na disk. Ali pritom se koristi i fdatasync()<\/code>. U kodu<\/a><\/noindex> RocksDB ima zanimljive komentare na tu temu. Na primjer, \u010dini se da poziv sync_file_range()<\/code> prilikom kori\u0161tenja ZFS ne dovodi do ispu\u0161tanja podataka na disk. Iskustvo mi govori da kod koji se rijetko koristi, mo\u017ee sadr\u017eavati gre\u0161ke. Stoga bih preporu\u010dio da se ovaj sistemski poziv ne koristi bez krajnje nu\u017ede.<\/p>\n

Sistemski pozivi koji poma\u017eu osigurati trajno \u010duvanje podataka<\/h2>\n

\nDo\u0161ao sam do zaklju\u010dka da se za izvo\u0111enje ulazno\/izlaznih operacija koje osiguravaju pouzdano \u010duvanje podataka mogu koristiti tri pristupa. Svi oni zahtijevaju pozivanje funkcije fsync()<\/code> za direktorij u kojem je datoteka stvorena. Evo tih pristupa:<\/p>\n

    \n
  1. Poziv funkcije fdatasync()<\/code> ili fsync()<\/code> nakon funkcije write()<\/code> (bolje koristiti fdatasync()<\/code>).<\/li>\n
  2. Rad s opisnikom datoteke otvorenim s zastavicom O_DSYNC<\/code> ili O_SYNC<\/code> (bolje \u2014 s zastavicom O_DSYNC<\/code>).<\/li>\n
  3. Kori\u0161tenje naredbe pwritev2()<\/code> s oznakom RWF_DSYNC<\/code> ili RWF_SYNC<\/code> (preferabilno \u2014 s zastavicom RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Bilje\u0161ke o performansama<\/h2>\n

    \nNisam se bavio detaljnim mjerenjem performansi razli\u010ditih mehanizama koje sam istra\u017eivao. Primije\u0107ene razlike u brzini njihovog rada su vrlo male. To zna\u010di da se mogu varati, a to \u0161to pod drugim uvjetima isto mo\u017ee dati druge rezultate. Prvo \u0107u govoriti o onome \u0161to sna\u017enije utje\u010de na performanse, a zatim o onome \u0161to manje utje\u010de.<\/p>\n

      \n
    1. Ponovno pisanje podataka u datoteku je br\u017ee od pridru\u017eivanja podataka datoteci (dobitak u performansama mo\u017ee iznositi 2-100%). Pridru\u017eivanje podataka datoteci zahtijeva dodatne promjene u metapodacima datoteke, \u010dak i nakon sistemskog poziva fallocate()<\/code>, ali razmjeri ovog u\u010dinka se mogu mijenjati. Preporu\u010dujem, za osiguranje najboljih performansi, pozivanje fallocate()<\/code> za prethodno dodjeljivanje potrebnog prostora. Nakon toga, taj prostor treba izri\u010dito ispuniti nulama i pozvati fsync()<\/code>. Time \u0107e odgovaraju\u0107i blokovi u datote\u010dnom sustavu biti ozna\u010deni kao \u201edodijeljeni\u201c, a ne kao \u201eneodre\u0111eni\u201c. To daje malo (oko 2%) pobolj\u0161anje performansi. Osim toga, kod nekih diskova prva operacija pristupa bloku mo\u017ee se izvoditi sporije od drugih. To zna\u010di da punjenje prostora nulama mo\u017ee dovesti do zna\u010dajnog (oko 100%) pobolj\u0161anja performansi. Konkretno, to se mo\u017ee dogoditi s diskovima AWS EBS<\/a><\/noindex> (to su neovisni podaci, nisam ih mogao potvrditi). Isto vrijedi i za skladi\u0161ta GCP Persistent Disk<\/a><\/noindex> (a ovo su ve\u0107 slu\u017ebene informacije, potvr\u0111ene ispitivanjima). Drugi stru\u010dnjaci su napravili sli\u010dna zapa\u017eanja<\/a><\/noindex>, koja se odnose na razli\u010dite diskove.<\/li>\n
    2. \u0160to je manje sistemskih poziva \u2014 to su ve\u0107e performanse (dobitak mo\u017ee biti oko 5%). \u010cini se da je poziv open()<\/code> s oznakom O_DSYNC<\/code> ili poziv pwritev2()<\/code> s oznakom RWF_SYNC<\/code> br\u017ei od poziva fdatasync()<\/code>Sumnjam da je razlog u tome \u0161to se takvim pristupom smanjuje broj sistemskih poziva potrebnih za rje\u0161avanje iste zada\u0107e (jedan poziv umjesto dva). No, razlika u performansama je vrlo mala, stoga to mo\u017eete zanemariti i koristiti u aplikaciji ono \u0161to ne\u0107e komplikovati njezinu logiku.<\/li>\n<\/ol>\n

      \nAko vas zanima tema odr\u017eivog pohranjivanja podataka \u2014 evo nekoliko korisnih materijala:<\/p>\n