Bærekraftig datalagring og fil-API for Linux

Jeg, mens jeg undersøker bærekraften til datalagring i skytjenester, bestemte meg for å teste min forståelse av de grunnleggende prinsippene. Jeg begynte med å lese spesifikasjonen for NVMe for å forstå hvilke garantier for bærekraftig datalagring (det vil si garantier for at dataene vil være tilgjengelige etter et systemfeil) NVMe-disker gir oss. Jeg kom til følgende hovedkonklusjoner: man må anse data som skadet fra det øyeblikket skrivekommandoen er gitt, og frem til skriveprosessen er fullført på lagringsenheten. Imidlertid brukes systemanrop i de fleste dataskrivingsprogrammer helt uten problemer.

I dette materialet undersøker jeg mekanismene for bærekraftig datalagring som tilbys av Linux-fil-APIene. Det virker som om dette bør være enkelt: programmet kaller kommandoen write(), og etter at arbeidet med denne kommandoen er fullført, vil dataene være pålitelig lagret på disken. Men write() den bare kopierer applikasjonsdata inn i kjernebufferet, som ligger i RAM. For å tvinge systemet til å skrive dataene til disken, må man bruke noen ekstra mekanismer.

Generelt sett er dette materialet et sett med notater om hva jeg har lært om det emnet som interesserer meg. Hvis jeg kort oppsummerer det viktigste, kan jeg si at for å organisere bærekraftig datalagring må man bruke kommandoen fdatasync() eller åpne filer med flagget O_DSYNC. Hvis du ønsker å vite mer detaljert om hva som skjer med dataene fra programkoden til disken, se på denne artikkelen.

Særtrekk ved bruk av funksjonen write()

Systemanropet write() er definert i standarden IEEE POSIX som et forsøk på å skrive data til en filbeskrivelse. Etter en vellykket fullføring av arbeidet write() bør leseoperasjoner returnere akkurat de bytene som ble skrevet tidligere, også selv om dataene blir aksessert fra andre prosesser eller tråder (her er den relevante delen av POSIX-standarden). Her, i seksjonen som omhandler samhandling mellom tråder og vanlige filoperasjoner, finnes det en merknad som sier at hvis hver av de to trådene kaller disse funksjonene, må hvert kall se enten alle de angitte konsekvensene som følge av utførelsen av det andre kallet, eller ikke se noen konsekvenser i det hele tatt. Dette medfører at alle filoperasjoner for inn- og ut-data må opprettholde låsing av ressursen de jobber med.

Betyr dette at operasjonen write() er atomær? Tekniskt sett – ja. Data lesingsoperasjoner må returnere enten alt, eller ingenting av det som ble skrevet med write(). Men operasjonen write(), i henhold til standarden, er ikke obligatorisk for å fullføre ved å skrive alt som den ble foreslått å skrive. Den kan tillate å skrive bare en del av dataene. For eksempel kan vi ha to tråder, hver av dem legger til 1024 byte til en fil, beskrevet av den samme filbeskriveren. Fra standardens synspunkt er resultatet akseptabelt når hver av skriveoperasjonene bare kan legge til én byte til filen. Disse operasjonene vil forbli atomære, men etter at de er fullført, vil dataene de skrev til filen bli blandet. Her er en veldig interessant diskusjon om dette emnet på Stack Overflow.

Funksjonene fsync() og fdatasync()

Den enkleste måten å skrive data til disk på er ved å kalle funksjonen fsync(). Denne funksjonen ber operativsystemet om å overføre alle modifiserte blokker fra bufferen til disken. Dette inkluderer også all metadata for filen (tilgangstid, tid for filmodifikasjon, osv.). Jeg tror behovet for disse metadataene sjelden oppstår, så hvis du vet at de ikke er viktige for deg, kan du bruke funksjonen fdatasync(). I dokumentasjonen om fdatasync() sies det at under arbeidet med denne funksjonen lagres det på disken så mye metadata som "er nødvendig for korrekt utførelse av de påfølgende lesing av data-operasjonene". Og dette er akkurat det som bekymrer de fleste applikasjoner.

Et av problemene som kan oppstå her, er at disse mekanismene ikke garanterer at filen vil være mulig å oppdage etter en potensiell feil. Spesielt når man oppretter en ny fil, må man kalle fsync() 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() there is no way for the file to know which directory's data also needs to be flushed to disk (here you can read more about it). It seems that the ext4 file system is capable of automatically applying fsync() to directories containing corresponding files, but this may not be the case with other file systems.

This mechanism may be implemented differently in different file systems. I used blktrace 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() a little faster fsync(). The utility blktrace indicates that fdatasync() typically writes less data to disk (in ext4 fsync() writes 20 KiB, and fdatasync() — 16 KiB). In addition, I found out that XFS is a bit faster than ext4. And here with the help of blktrace it was possible to find out that fdatasync() flushes less data to disk (4 KiB in XFS).

Ambiguous situations arising from the use of fsync()

I can recall three ambiguous situations regarding fsync(), with which I encountered in practice.

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(), which provided good guarantees for stable data storage. In the file system in use at that time, ext3, the function fsync() 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å knappen i Firefox kunne initiere skriving av megabytes med data til harddisken, noe som kunne ta mange sekunder. Løsningen på problemet, så langt jeg forstod fra dette materialet, var å flytte databasehåndteringen til asynkrone bakgrunnsoppgaver. Dette betyr at tidligere i Firefox ble det implementert strengere krav til datalagringens pålitelighet enn det som faktisk var nødvendig, og egenskapene til filsystemet ext3 forverret bare dette problemet.

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()For å 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 å forbedre ytelsen (som standard forblir data i denne tilstanden i 30 sekunder, noe som kan justeres med dirty_expire_centisecs; here man kan finne mer materiale om dette). Dette betyr at store mengder data kan gå tapt irreversibelt etter et krasj. Løsningen på dette problemet er å bruke fsync() i applikasjoner som trenger å sikre pålitelig datalagring og maksimalt beskytte dem mot konsekvensene av krasj. Funksjonen fsync() fungerer betydelig bedre med ext4 enn med ext3. Ulempen med denne tilnærmingen er at dens anvendelse, som før, bremser utførelsen av visse operasjoner, som installasjon av programmer. Se detaljer om dette her og her.

Det tredje problemet, angående fsync(), oppsto i 2018. Da, som en del av PostgreSQL-prosjektet, ble det fastslått at hvis funksjonen fsync() møter en feil, merker den "skitne" sider som "rene". Som et resultat blir de påfølgende kallene fsync() man kan ikke gjøre noe med slike sider. På 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() er sjeldne, applikasjonen kan nesten ingenting gjøre for å takle problemet. I dag, når dette skjer, krasjer PostgreSQL og andre applikasjoner. Her, i artikkelen «Kan applikasjoner komme seg fra fsync-feil?», blir dette problemet undersøkt i detalj. For øyeblikket er den beste løsningen på dette problemet å bruke Direct I/O med flagget O_SYNC eller med flagget O_DSYNC. Med denne tilnærmingen vil systemet rapportere om feil som kan oppstå under spesifikke dataskriveoperasjoner, men denne tilnærmingen krever at applikasjonen administrerer buffere selv. Les mer om dette her og her.

Åpning av filer med flaggene O_SYNC og O_DSYNC

La oss gå tilbake til diskusjonen om mekanismer i Linux som sikrer vedvarende datalagring. Det handler spesifikt om bruk av flagget O_SYNC eller flagget O_DSYNC ved åpning av filer med systemanropet open(). Med denne tilnærmingen blir hver dataskriving vurdert som om kommandoene write() systemet får, henholdsvis, kommandoer fsync() og fdatasync(). I spesifikasjonene fra POSIX kalles dette «Synchronized I/O File Integrity Completion» og «Data Integrity Completion». Den største fordelen med denne tilnærmingen er at for å sikre dataintegritet må man bare gjøre ett systemanrop, ikke to (for eksempel — write() og fdatasync()). Den største ulempen med denne tilnærmingen er at alle skriveoperasjoner som bruker den aktuelle filbeskrivelsen vil bli synkronisert, noe som kan begrense mulighetene for å strukturere applikasjonskoden.

Bruk av Direct I/O med flagget O_DIRECT

Systemanropet open() støtter flagget O_DIRECT, som er ment for å omgå operativsystemets buffer og utføre I/O-operasjoner ved å samhandle direkte med disken. Dette betyr i mange tilfeller at skrivekommandoer utstedt av programmet vil bli direkte overført til kommandoer som er målrettet mot diskoperasjoner. Men generelt er ikke denne mekanismen en erstatning for funksjonene fsync() eller fdatasync(). Poenget er at selve disken kan utsette eller cache de relevante data skrive kommandoene. Og, hva som er verre, i noen spesielle tilfeller kan I/O-operasjoner utført med flagget O_DIRECT, oversettes til tradisjonelle bufferiserte operasjoner. Det er enklest å løse dette problemet ved å åpne filer med flagget O_DSYNC, noe som vil bety at det vil være et kall etter hver skriveoperasjon fdatasync().

Det har vist seg at filsystemet XFS nylig har fått en 'hurtigvei' for O_DIRECT|O_DSYNC-skriving av data. Hvis en blokk blir overskrevet med bruk av O_DIRECT|O_DSYNC, så vil XFS, i stedet for å tømme cachen, utføre FUA-skrivekommandoen dersom enheten støtter det. Jeg bekreftet dette ved å bruke verktøyet blktrace i Linux 5.4/Ubuntu 20.04. Denne tilnærmingen bør være mer effektiv, da den skriver et minimum av data til disken og samtidig bruker én operasjon snarere enn to (skrive og tømme cache). Jeg fant en lenke til patch 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å vidt jeg vet, er XFS det eneste filsystemet som så langt støtter dette.

sync_file_range()

I Linux finnes det et systemkall sync_file_range(), 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å at det skal fullføres. Men det står i hjelpedokumentasjonen for sync_file_range() at denne kommandoen er 'svært farlig'. Den anbefales ikke til bruk. Egenskapene og farene sync_file_range() er veldig godt beskrevet i dette materialet. I særdeleshet ser det ut til at dette systemkallet bruker RocksDB til å styre når kjernen tømmer 'skitne' data til disk. Men samtidig, for å sikre varig datalagring, brukes også fdatasync(). I koden Det er interessante kommentarer om dette i RocksDB. For eksempel ser det ut til at kallet sync_file_range() når det brukes med ZFS ikke fører til at data skrives til disk. Erfaring forteller meg at kode som sjelden brukes, kan inneholde feil. Derfor ville jeg anbefale å ikke bruke dette systemkallet uten absolutt nødvendighet.

Systemkall som hjelper til med å sikre varig datalagring

Jeg har kommet frem til at for å utføre inn-/utgangsoperasjoner som gir pålitelig datalagring, kan man bruke tre tilnærminger. Alle krever et funksjonskall fsync() for katalogen der filen er opprettet. Her er disse tilnærmingene:

1. Kall på funksjonen fdatasync() eller fsync() etter funksjonen write() (bruk helst fdatasync()).
2. Arbeid med filbeskrivelsen, åpnet med flagget O_DSYNC eller O_SYNC (bedre — med flagget O_DSYNC).
3. Bruk av kommandoen pwritev2() med flagget RWF_DSYNC eller RWF_SYNC (foretrukket — med flagget RWF_DSYNC).

Notater om ytelse

Jeg har ikke utført grundige målinger av ytelsen til de forskjellige mekanismene jeg har undersøkt. Mine observerte hastighetsforskjeller er ganske små. Dette betyr at jeg kan ta feil, og at det i andre forhold kan gi andre resultater. Først vil jeg fortelle hva som påvirker ytelsen mest, og deretter hva som har mindre innvirkning.

1. Overskriving av fildata er raskere enn å legge til data til filen (ytelsesgevinsten kan være 2-100%). Å legge til data til filen krever ytterligere endringer i filens metainformasjon, selv etter systemkallet fallocate(), men omfanget av denne effekten kan variere. Jeg anbefaler å kalle fallocate() for å forhåndsallokere nødvendig plass. Deretter må dette området eksplisitt fylles med nuller og kalle fsync(). Dette sørger for at de aktuelle blokkene i filsystemet merkes som «allokert», og ikke som «ikke-allokert». Dette gir en liten (omtrent 2%) ytelsesforbedring. I tillegg kan første tilgang til en blokk på noen disker være tregere enn andre. Dette betyr at fylling av plass med nuller kan føre til en betydelig (omtrent 100%) ytelsesforbedring. Spesielt kan dette skje med disker AWS EBS (dette er ikke-offisielle data, jeg har ikke kunnet bekrefte dem). Det samme gjelder for lagringer GCP Persistent Disk (og dette er allerede offisiell informasjon bekreftet av tester). Andre spesialister har gjort de samme observasjonene, relatert til forskjellige disker.
2. Jo færre systemkall, jo høyere ytelse (gevinsten kan være omtrent 5%). Det ser ut til at å kalle open() med flagget O_DSYNC eller kalle pwritev2() med flagget RWF_SYNC raskall av fdatasync(). Eg har ei mistanke om at dette har å gjere med at når ein tar denne tilnærminga, så spelar det ei rolle at for å løyse den same oppgåva må ein utføre færre systemkall (ein kall i staden for to). Men forskjellen i ytelse er svært liten, så du kan heilt klart ignorere det og bruke det i applikasjonen som ikkje vil føre til komplisering av logikken.

Dersom du er interessert i temaet omhaldande datalagring — her er nokre nyttige ressursar:

• I/O tilgangsmetodar — ei oversikt over grunnprinsippa for inndatakontroll.
• Sikring av at data når disken — ein fortelling om kva som skjer med data på veg frå applikasjonen til disken.
• Når bør du fsync katalogen som inneheld — svaret på spørsmålet om når det er nødvendig å bruke fsync() for katalogar. I korte trekk, dette bør gjerast ved oppretting av ei ny fil, og grunnen til denne anbefalinga er at det i Linux kan finnast mange referansar til den same fila.
• SQL Server på Linux: FUA-internals — her finnes det ei beskrivelse av korleis robust datalagring er implementert i SQL Server på Linux-plattforma. Her er det einige interessante samanlikningar mellom systemkall i Windows og Linux. Eg er nesten sikker på at eg lærte om FUA-optimalisering av XFS takka vere dette materialet.

Har du tapt data som du trudde var sikkert lagra på disken?

Kilde: habr.com