{"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\/no\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"B\u00e6rekraftig datalagring og fil-API for Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jeg, mens jeg unders\u00f8ker b\u00e6rekraften til datalagring i skytjenester, bestemte meg for \u00e5 teste min forst\u00e5else av de grunnleggende prinsippene. Jeg begynte med \u00e5 lese spesifikasjonen for NVMe<\/a><\/noindex> for \u00e5 forst\u00e5 hvilke garantier for b\u00e6rekraftig datalagring (det vil si garantier for at dataene vil v\u00e6re tilgjengelige etter et systemfeil) NVMe-disker gir oss. Jeg kom til f\u00f8lgende hovedkonklusjoner: man m\u00e5 anse data som skadet fra det \u00f8yeblikket skrivekommandoen er gitt, og frem til skriveprosessen er fullf\u00f8rt p\u00e5 lagringsenheten. Imidlertid brukes systemanrop i de fleste dataskrivingsprogrammer helt uten problemer.<\/p>\n

I dette materialet unders\u00f8ker jeg mekanismene for b\u00e6rekraftig datalagring som tilbys av Linux-fil-APIene. Det virker som om dette b\u00f8r v\u00e6re enkelt: programmet kaller kommandoen write()<\/code>, og etter at arbeidet med denne kommandoen er fullf\u00f8rt, vil dataene v\u00e6re p\u00e5litelig lagret p\u00e5 disken. Men write()<\/code> den bare kopierer applikasjonsdata inn i kjernebufferet, som ligger i RAM. For \u00e5 tvinge systemet til \u00e5 skrive dataene til disken, m\u00e5 man bruke noen ekstra mekanismer.<\/p>\n

\"B\u00e6rekraftig<\/a><\/noindex><\/p>\n

Generelt sett er dette materialet et sett med notater om hva jeg har l\u00e6rt om det emnet som interesserer meg. Hvis jeg kort oppsummerer det viktigste, kan jeg si at for \u00e5 organisere b\u00e6rekraftig datalagring m\u00e5 man bruke kommandoen fdatasync()<\/code> eller \u00e5pne filer med flagget O_DSYNC<\/code>. Hvis du \u00f8nsker \u00e5 vite mer detaljert om hva som skjer med dataene fra programkoden til disken, se p\u00e5 denne<\/a><\/noindex> artikkelen.
\n<\/a><\/noindex><\/p>\n

S\u00e6rtrekk ved bruk av funksjonen write()<\/h2>\n

\nSystemanropet write()<\/code> er definert i standarden IEEE POSIX<\/a><\/noindex> som et fors\u00f8k p\u00e5 \u00e5 skrive data til en filbeskrivelse. Etter en vellykket fullf\u00f8ring av arbeidet write()<\/code> b\u00f8r leseoperasjoner returnere akkurat de bytene som ble skrevet tidligere, ogs\u00e5 selv om dataene blir aksessert fra andre prosesser eller tr\u00e5der (her<\/a><\/noindex> er den relevante delen av POSIX-standarden). Her<\/a><\/noindex>, i seksjonen som omhandler samhandling mellom tr\u00e5der og vanlige filoperasjoner, finnes det en merknad som sier at hvis hver av de to tr\u00e5dene kaller disse funksjonene, m\u00e5 hvert kall se enten alle de angitte konsekvensene som f\u00f8lge av utf\u00f8relsen av det andre kallet, eller ikke se noen konsekvenser i det hele tatt. Dette medf\u00f8rer at alle filoperasjoner for inn- og ut-data m\u00e5 opprettholde l\u00e5sing av ressursen de jobber med.<\/p>\n

Betyr dette at operasjonen write()<\/code> er atom\u00e6r? Tekniskt sett \u2013 ja. Data lesingsoperasjoner m\u00e5 returnere enten alt, eller ingenting av det som ble skrevet med write()<\/code>. Men operasjonen write()<\/code>, i henhold til standarden, er ikke obligatorisk for \u00e5 fullf\u00f8re ved \u00e5 skrive alt som den ble foresl\u00e5tt \u00e5 skrive. Den kan tillate \u00e5 skrive bare en del av dataene. For eksempel kan vi ha to tr\u00e5der, hver av dem legger til 1024 byte til en fil, beskrevet av den samme filbeskriveren. Fra standardens synspunkt er resultatet akseptabelt n\u00e5r hver av skriveoperasjonene bare kan legge til \u00e9n byte til filen. Disse operasjonene vil forbli atom\u00e6re, men etter at de er fullf\u00f8rt, vil dataene de skrev til filen bli blandet. Her er<\/a><\/noindex> en veldig interessant diskusjon om dette emnet p\u00e5 Stack Overflow.<\/p>\n

Funksjonene fsync() og fdatasync()<\/h2>\n

\nDen enkleste m\u00e5ten \u00e5 skrive data til disk p\u00e5 er ved \u00e5 kalle funksjonen fsync()<\/a><\/noindex>. Denne funksjonen ber operativsystemet om \u00e5 overf\u00f8re alle modifiserte blokker fra bufferen til disken. Dette inkluderer ogs\u00e5 all metadata for filen (tilgangstid, tid for filmodifikasjon, osv.). Jeg tror behovet for disse metadataene sjelden oppst\u00e5r, s\u00e5 hvis du vet at de ikke er viktige for deg, kan du bruke funksjonen fdatasync()<\/code>. I dokumentasjonen<\/a><\/noindex> om fdatasync()<\/code> sies det at under arbeidet med denne funksjonen lagres det p\u00e5 disken s\u00e5 mye metadata som \"er n\u00f8dvendig for korrekt utf\u00f8relse av de p\u00e5f\u00f8lgende lesing av data-operasjonene\". Og dette er akkurat det som bekymrer de fleste applikasjoner.<\/p>\n

Et av problemene som kan oppst\u00e5 her, er at disse mekanismene ikke garanterer at filen vil v\u00e6re mulig \u00e5 oppdage etter en potensiell feil. Spesielt n\u00e5r man oppretter en ny fil, m\u00e5 man kalle fsync()<\/code> for the directory that contains it. Otherwise, after a crash, it may happen that this file does not exist. The reason for this is that in UNIX, due to the use of hard links, a file can exist in multiple directories. Therefore, when called, fsync()<\/code> there is no way for the file to know which directory's data also needs to be flushed to disk (here<\/a><\/noindex> you can read more about it). It seems that the ext4 file system is capable of automatically<\/a><\/noindex> applying fsync()<\/code> to directories containing corresponding files, but this may not be the case with other file systems.<\/p>\n

This mechanism may be implemented differently in different file systems. I used blktrace<\/a><\/noindex> to find out what disk operations are used in the ext4 and XFS file systems. Both produce usual write commands to disk for both file contents and the file system journal, flushing the cache and completing the operation by executing FUA (Force Unit Access, writing data directly to disk, bypassing the cache) in the journal. They probably do this to confirm the fact of performing the operation. On disks that do not support FUA, this causes two cache flushes. My experiments showed that fdatasync()<\/code> a little faster fsync()<\/code>. The utility blktrace<\/code> indicates that fdatasync()<\/code> typically writes less data to disk (in ext4 fsync()<\/code> writes 20 KiB, and fdatasync()<\/code> \u2014 16 KiB). In addition, I found out that XFS is a bit faster than ext4. And here with the help of blktrace<\/code> it was possible to find out that fdatasync()<\/code> flushes less data to disk (4 KiB in XFS).<\/p>\n

Ambiguous situations arising from the use of fsync()<\/h2>\n

\nI can recall three ambiguous situations regarding fsync()<\/code>, with which I encountered in practice.<\/p>\n

The first such case occurred in 2008. At that time, the Firefox 3 interface would 'freeze' when writing a large number of files to disk. The problem was that in the implementation of the interface, SQLite was used to store information about its state. After each change in the interface, the function was called fsync()<\/code>, which provided good guarantees for stable data storage. In the file system in use at that time, ext3, the function fsync()<\/code> den nedlastet alt \"skitne\" sider i systemet til disken, ikke bare de som var knyttet til den aktuelle filen. Dette betydde at et klikk p\u00e5 knappen i Firefox kunne initiere skriving av megabytes med data til harddisken, noe som kunne ta mange sekunder. L\u00f8sningen p\u00e5 problemet, s\u00e5 langt jeg forstod fra dette<\/a><\/noindex> materialet, var \u00e5 flytte databaseh\u00e5ndteringen til asynkrone bakgrunnsoppgaver. Dette betyr at tidligere i Firefox ble det implementert strengere krav til datalagringens p\u00e5litelighet enn det som faktisk var n\u00f8dvendig, og egenskapene til filsystemet ext3 forverret bare dette problemet.<\/p>\n

Det andre avviket skjedde i 2009. Da, etter et systemkrasj, opplevde brukere av det nye filsystemet ext4 at mange nylig opprettede filer hadde null lengde, mens dette ikke skjedde med det eldre filsystemet ext3. I forrige avsnitt nevnte jeg at ext3 skrev for mye data til disken, noe som betydelig forsinket ytelsen. fsync()<\/code>For \u00e5 forbedre situasjonen, skriver ext4 til disken kun de \"skitne\" sidene som er knyttet til den spesifikke filen. Data fra andre filer forblir i minnet i mye lengre tid enn ved bruk av ext3. Dette ble gjort for \u00e5 forbedre ytelsen (som standard forblir data i denne tilstanden i 30 sekunder, noe som kan justeres med dirty_expire_centisecs<\/a><\/noindex>; here<\/a><\/noindex> man kan finne mer materiale om dette). Dette betyr at store mengder data kan g\u00e5 tapt irreversibelt etter et krasj. L\u00f8sningen p\u00e5 dette problemet er \u00e5 bruke fsync()<\/code> i applikasjoner som trenger \u00e5 sikre p\u00e5litelig datalagring og maksimalt beskytte dem mot konsekvensene av krasj. Funksjonen fsync()<\/code> fungerer betydelig bedre med ext4 enn med ext3. Ulempen med denne tiln\u00e6rmingen er at dens anvendelse, som f\u00f8r, bremser utf\u00f8relsen av visse operasjoner, som installasjon av programmer. Se detaljer om dette her<\/a><\/noindex> og her<\/a><\/noindex>.<\/p>\n

Det tredje problemet, ang\u00e5ende fsync()<\/code>, oppsto i 2018. Da, som en del av PostgreSQL-prosjektet, ble det fastsl\u00e5tt at hvis funksjonen fsync()<\/code> m\u00f8ter en feil, merker den \"skitne\" sider som \"rene\". Som et resultat blir de p\u00e5f\u00f8lgende kallene fsync()<\/code> man kan ikke gj\u00f8re noe med slike sider. P\u00e5 grunn av dette lagres de modifiserte sidene i minnet og skrives aldri til disken. Dette er en virkelig katastrofe, ettersom applikasjonen vil tro at visse data er skrevet til disken, mens det i virkeligheten ikke er tilfelle. Slike feil fsync()<\/code> er sjeldne, applikasjonen kan nesten ingenting gj\u00f8re for \u00e5 takle problemet. I dag, n\u00e5r dette skjer, krasjer PostgreSQL og andre applikasjoner. Her<\/a><\/noindex>, i artikkelen \u00abKan applikasjoner komme seg fra fsync-feil?\u00bb, blir dette problemet unders\u00f8kt i detalj. For \u00f8yeblikket er den beste l\u00f8sningen p\u00e5 dette problemet \u00e5 bruke Direct I\/O med flagget O_SYNC<\/code> eller med flagget O_DSYNC<\/code>. Med denne tiln\u00e6rmingen vil systemet rapportere om feil som kan oppst\u00e5 under spesifikke dataskriveoperasjoner, men denne tiln\u00e6rmingen krever at applikasjonen administrerer buffere selv. Les mer om dette her<\/a><\/noindex> og her<\/a><\/noindex>.<\/p>\n

\u00c5pning av filer med flaggene O_SYNC og O_DSYNC<\/h2>\n

\nLa oss g\u00e5 tilbake til diskusjonen om mekanismer i Linux som sikrer vedvarende datalagring. Det handler spesifikt om bruk av flagget O_SYNC<\/code> eller flagget O_DSYNC<\/code> ved \u00e5pning av filer med systemanropet open()<\/a><\/noindex>. Med denne tiln\u00e6rmingen blir hver dataskriving vurdert som om kommandoene write()<\/code> systemet f\u00e5r, henholdsvis, kommandoer fsync()<\/code> og fdatasync()<\/code>. I spesifikasjonene fra POSIX<\/a><\/noindex> kalles dette \u00abSynchronized I\/O File Integrity Completion\u00bb og \u00abData Integrity Completion\u00bb. Den st\u00f8rste fordelen med denne tiln\u00e6rmingen er at for \u00e5 sikre dataintegritet m\u00e5 man bare gj\u00f8re ett systemanrop, ikke to (for eksempel \u2014 write()<\/code> og fdatasync()<\/code>). Den st\u00f8rste ulempen med denne tiln\u00e6rmingen er at alle skriveoperasjoner som bruker den aktuelle filbeskrivelsen vil bli synkronisert, noe som kan begrense mulighetene for \u00e5 strukturere applikasjonskoden.<\/p>\n

Bruk av Direct I\/O med flagget O_DIRECT<\/h2>\n

\nSystemanropet open()<\/code> st\u00f8tter flagget O_DIRECT<\/code>, som er ment for \u00e5 omg\u00e5 operativsystemets buffer og utf\u00f8re I\/O-operasjoner ved \u00e5 samhandle direkte med disken. Dette betyr i mange tilfeller at skrivekommandoer utstedt av programmet vil bli direkte overf\u00f8rt til kommandoer som er m\u00e5lrettet mot diskoperasjoner. Men generelt er ikke denne mekanismen en erstatning for funksjonene fsync()<\/code> eller fdatasync()<\/code>. Poenget er at selve disken kan utsette eller cache<\/a><\/noindex> de relevante data skrive kommandoene. Og, hva som er verre, i noen spesielle tilfeller kan I\/O-operasjoner utf\u00f8rt med flagget O_DIRECT<\/code>, oversettes<\/a><\/noindex> til tradisjonelle bufferiserte operasjoner. Det er enklest \u00e5 l\u00f8se dette problemet ved \u00e5 \u00e5pne filer med flagget O_DSYNC<\/code>, noe som vil bety at det vil v\u00e6re et kall etter hver skriveoperasjon fdatasync()<\/code>.<\/p>\n

Det har vist seg at filsystemet XFS nylig har f\u00e5tt en 'hurtigvei' for O_DIRECT|O_DSYNC<\/code>-skriving av data. Hvis en blokk blir overskrevet med bruk av O_DIRECT|O_DSYNC<\/code>, s\u00e5 vil XFS, i stedet for \u00e5 t\u00f8mme cachen, utf\u00f8re FUA-skrivekommandoen dersom enheten st\u00f8tter det. Jeg bekreftet dette ved \u00e5 bruke verkt\u00f8yet blktrace<\/code> i Linux 5.4\/Ubuntu 20.04. Denne tiln\u00e6rmingen b\u00f8r v\u00e6re mer effektiv, da den skriver et minimum av data til disken og samtidig bruker \u00e9n operasjon snarere enn to (skrive og t\u00f8mme cache). Jeg fant en lenke til patch<\/a><\/noindex> fra kjernen i 2018, der denne mekanismen er implementert. Det er en diskusjon der som omhandler bruk av denne optimaliseringen i andre filsystemer, men s\u00e5 vidt jeg vet, er XFS det eneste filsystemet som s\u00e5 langt st\u00f8tter dette.<\/p>\n

sync_file_range()<\/h2>\n

\nI Linux finnes det et systemkall sync_file_range()<\/a><\/noindex>, som lar deg skrive til disk bare en del av en fil, ikke hele filen. Dette systemkallet initierer en asynkron skriving av data og venter ikke p\u00e5 at det skal fullf\u00f8res. Men det st\u00e5r i hjelpedokumentasjonen for sync_file_range()<\/code> at denne kommandoen er 'sv\u00e6rt farlig'. Den anbefales ikke til bruk. Egenskapene og farene sync_file_range()<\/code> er veldig godt beskrevet i dette<\/a><\/noindex> materialet. I s\u00e6rdeleshet ser det ut til at dette systemkallet bruker RocksDB til \u00e5 styre n\u00e5r kjernen t\u00f8mmer 'skitne' data til disk. Men samtidig, for \u00e5 sikre varig datalagring, brukes ogs\u00e5 fdatasync()<\/code>. I koden<\/a><\/noindex> Det er interessante kommentarer om dette i RocksDB. For eksempel ser det ut til at kallet sync_file_range()<\/code> n\u00e5r det brukes med ZFS ikke f\u00f8rer til at data skrives til disk. Erfaring forteller meg at kode som sjelden brukes, kan inneholde feil. Derfor ville jeg anbefale \u00e5 ikke bruke dette systemkallet uten absolutt n\u00f8dvendighet.<\/p>\n

Systemkall som hjelper til med \u00e5 sikre varig datalagring<\/h2>\n

\nJeg har kommet frem til at for \u00e5 utf\u00f8re inn-\/utgangsoperasjoner som gir p\u00e5litelig datalagring, kan man bruke tre tiln\u00e6rminger. Alle krever et funksjonskall fsync()<\/code> for katalogen der filen er opprettet. Her er disse tiln\u00e6rmingene:<\/p>\n

    \n
  1. Kall p\u00e5 funksjonen fdatasync()<\/code> eller fsync()<\/code> etter funksjonen write()<\/code> (bruk helst fdatasync()<\/code>).<\/li>\n
  2. Arbeid med filbeskrivelsen, \u00e5pnet med flagget O_DSYNC<\/code> eller O_SYNC<\/code> (bedre \u2014 med flagget O_DSYNC<\/code>).<\/li>\n
  3. Bruk av kommandoen pwritev2()<\/code> med flagget RWF_DSYNC<\/code> eller RWF_SYNC<\/code> (foretrukket \u2014 med flagget RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Notater om ytelse<\/h2>\n

    \nJeg har ikke utf\u00f8rt grundige m\u00e5linger av ytelsen til de forskjellige mekanismene jeg har unders\u00f8kt. Mine observerte hastighetsforskjeller er ganske sm\u00e5. Dette betyr at jeg kan ta feil, og at det i andre forhold kan gi andre resultater. F\u00f8rst vil jeg fortelle hva som p\u00e5virker ytelsen mest, og deretter hva som har mindre innvirkning.<\/p>\n

      \n
    1. Overskriving av fildata er raskere enn \u00e5 legge til data til filen (ytelsesgevinsten kan v\u00e6re 2-100%). \u00c5 legge til data til filen krever ytterligere endringer i filens metainformasjon, selv etter systemkallet fallocate()<\/code>, men omfanget av denne effekten kan variere. Jeg anbefaler \u00e5 kalle fallocate()<\/code> for \u00e5 forh\u00e5ndsallokere n\u00f8dvendig plass. Deretter m\u00e5 dette omr\u00e5det eksplisitt fylles med nuller og kalle fsync()<\/code>. Dette s\u00f8rger for at de aktuelle blokkene i filsystemet merkes som \u00aballokert\u00bb, og ikke som \u00abikke-allokert\u00bb. Dette gir en liten (omtrent 2%) ytelsesforbedring. I tillegg kan f\u00f8rste tilgang til en blokk p\u00e5 noen disker v\u00e6re tregere enn andre. Dette betyr at fylling av plass med nuller kan f\u00f8re til en betydelig (omtrent 100%) ytelsesforbedring. Spesielt kan dette skje med disker AWS EBS<\/a><\/noindex> (dette er ikke-offisielle data, jeg har ikke kunnet bekrefte dem). Det samme gjelder for lagringer GCP Persistent Disk<\/a><\/noindex> (og dette er allerede offisiell informasjon bekreftet av tester). Andre spesialister har gjort de samme observasjonene<\/a><\/noindex>, relatert til forskjellige disker.<\/li>\n
    2. Jo f\u00e6rre systemkall, jo h\u00f8yere ytelse (gevinsten kan v\u00e6re omtrent 5%). Det ser ut til at \u00e5 kalle open()<\/code> med flagget O_DSYNC<\/code> eller kalle pwritev2()<\/code> med flagget RWF_SYNC<\/code> raskall av fdatasync()<\/code>. Eg har ei mistanke om at dette har \u00e5 gjere med at n\u00e5r ein tar denne tiln\u00e6rminga, s\u00e5 spelar det ei rolle at for \u00e5 l\u00f8yse den same oppg\u00e5va m\u00e5 ein utf\u00f8re f\u00e6rre systemkall (ein kall i staden for to). Men forskjellen i ytelse er sv\u00e6rt liten, s\u00e5 du kan heilt klart ignorere det og bruke det i applikasjonen som ikkje vil f\u00f8re til komplisering av logikken.<\/li>\n<\/ol>\n

      \nDersom du er interessert i temaet omhaldande datalagring \u2014 her er nokre nyttige ressursar:<\/p>\n