{"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\/da\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"B\u00e6redygtig lagring af data og fil-API'er i Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jeg, mens jeg unders\u00f8ger datalagringsholdbarhed i cloud-systemer, besluttede at teste mig selv for at sikre, at jeg forst\u00e5r de grundl\u00e6ggende ting. Jeg startede med at l\u00e6se NVMe-specifikationen<\/a><\/noindex> for at forst\u00e5, hvilke garantier vedr\u00f8rende holdbar lagring af data (det vil sige garantier for, at dataene vil v\u00e6re tilg\u00e6ngelige efter et systemfejl), NVMe-diskene giver os. Mine f\u00f8lgende hovedkonklusioner er: Det skal betragtes, at dataene er beskadigede fra det \u00f8jeblik, hvor skrivekommandoen er givet, til det \u00f8jeblik, hvor de er f\u00e6rdige med at blive skrevet til informationsmediet. Dog anvendes systemopkald helt afslappet i de fleste programmer til dataoptagelse.<\/p>\n

I dette materiale unders\u00f8ger jeg de mekanismer for holdbar datalagring, der tilbydes af Linux-filsystem-API'er. Det virker til at v\u00e6re enkelt: Programmet kalder kommandoen write()<\/code>, og efter at denne kommando er afsluttet, skulle dataene v\u00e6re sikkert gemt p\u00e5 disken. Men write()<\/code> kopierer blot applikationernes data til kernelens cache, der ligger i RAM. For at tvinge systemet til at skrive data til disken, kr\u00e6ves nogle ekstra mekanismer.<\/p>\n

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

Generelt er dette materiale en samling noter om, hvad jeg har l\u00e6rt om det emne, der interesserer mig. Hvis man meget kort skal fort\u00e6lle om det vigtigste, er det, at for at organisere holdbar datalagring, skal man bruge kommandoen fdatasync()<\/code> eller \u00e5bne filer med flaget O_DSYNC<\/code>. Hvis du er interesseret i detaljerne om, hvad der sker med dataene, n\u00e5r de transporteres fra programkoden til disken, kan du se p\u00e5 denne<\/a><\/noindex> artiklen.
\n<\/a><\/noindex><\/p>\n

Egenskaber ved brug af funktionen write()<\/h2>\n

\nSystemopkald write()<\/code> defineres i standarden IEEE POSIX<\/a><\/noindex> som et fors\u00f8g p\u00e5 at skrive data til en filbeskriver. Efter en vellykket afslutning write()<\/code> skal datal\u00e6sningsoperationer returnere netop de bytes, der tidligere var skrevet, hvilket skal ske, selvom dataene tilg\u00e5s fra andre processer eller tr\u00e5de (her<\/a><\/noindex> den relevante sektion i POSIX-standarden). Her<\/a><\/noindex>, i afsnittet om interaktionen mellem tr\u00e5de og almindelige filoperationer er der en bem\u00e6rkning, der siger, at hvis hver af de to tr\u00e5de kalder disse funktioner, s\u00e5 skal hver opkald se enten alle de angivne konsekvenser, som udf\u00f8relsen af den anden opkald medf\u00f8rer, eller slet ingen konsekvenser. Dette f\u00f8rer til den konklusion, at alle fil I\/O-operationer skal holde l\u00e5s p\u00e5 den ressource, de arbejder med.<\/p>\n

Betyder det, at operationen write()<\/code> er atomar? Teknisk set - ja. Data l\u00e6seoperationer skal returnere enten alt eller intet af det, der er blevet skrevet med write()<\/code>. Men operationen write()<\/code>, if\u00f8lge standarden, beh\u00f8ver ikke n\u00f8dvendigvis at afslutte ved at skrive alt, hvad den blev bedt om at skrive. Den m\u00e5 kun skrive en del af dataene. For eksempel kan vi have to tr\u00e5de, der hver tilf\u00f8jer 1024 byte til en fil, der beskrives af den samme filbeskrivelse. Fra standardens synspunkt er et acceptabelt resultat, hvor hver af skriveoperationerne kun kan tilf\u00f8je en byte til filen. Disse operationer vil forblive atomare, men n\u00e5r de er f\u00e6rdige, vil de data, der er skrevet af dem til filen, v\u00e6re blandede. Her er<\/a><\/noindex> meget interessant diskussion om dette emne p\u00e5 Stack Overflow.<\/p>\n

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

\nDen enkleste m\u00e5de at t\u00f8mme data til disk p\u00e5 er ved at kalde funktionen fsync()<\/a><\/noindex>. Denne funktion beder operativsystemet om at overf\u00f8re alle modificerede blokke fra cachen til disken. Dette inkluderer ogs\u00e5 alle metadata for filen (adgangstid, \u00e6ndringstid for filen osv.). Jeg antager, at behovet for disse metadata sj\u00e6ldent opst\u00e5r, s\u00e5 hvis du ved, at de ikke er vigtige for dig, kan du bruge funktionen fdatasync()<\/code>. I hj\u00e6lp<\/a><\/noindex> efter fdatasync()<\/code> siger, at under denne funktions arbejde overf\u00f8res der til disken s\u00e5 meget metadata, som \"er n\u00f8dvendigt for korrekt udf\u00f8relse af de f\u00f8lgende data l\u00e6seoperationer\". Og det er netop det, der bekymrer de fleste applikationer.<\/p>\n

Et af de problemer, der kan opst\u00e5 her, er, at disse mekanismer ikke garanterer, at filen kan findes efter et muligt sammenbrud. Is\u00e6r n\u00e5r man opretter en ny fil, skal man kalde fsync()<\/code> for the directory that contains it. Otherwise, after a crash, it may turn out 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 several directories. Therefore, when calling fsync()<\/code> there is no way for the file to know which specific directory also needs to be flushed to disk (her<\/a><\/noindex> you can read more about this). It seems that the ext4 file system is capable automatisk<\/a><\/noindex> at anvende fsync()<\/code> of directories that contain the corresponding files, but this may not be the case with other file systems.<\/p>\n

This mechanism can be implemented differently in various file systems. I used blktrace<\/a><\/noindex> to find out which disk operations are used in the ext4 and XFS file systems. Both issue standard write commands to the disk for both file contents and the file system journal, flush the cache, and finish by performing an FUA write (Force Unit Access, writing data directly to disk, bypassing the cache) in the journal. They probably do this to confirm the operation's occurrence. On disks that do not support FUA, this causes two cache flushes. My experiments showed that fdatasync()<\/code> a bit faster fsync()<\/code>. Utility blktrace<\/code> indicates that fdatasync()<\/code> usually writes less data to disk (in ext4 fsync()<\/code> writes 20 KiB, while fdatasync()<\/code> \u2014 16 KiB). Additionally, I found that XFS is slightly 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 when using fsync()<\/h2>\n

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

The first such case occurred in 2008. At that time, the Firefox 3 interface would 'hang' if a large number of files were being written to disk. The problem was that the implementation of the interface used an SQLite database to store information about its state. After every change occurring in the interface, the function was called fsync()<\/code>, which provided good guarantees of data durability. In the ext3 file system used at that time, the function fsync()<\/code> skrev alt \"beskidt\" indhold tilbage til disken i systemet, og ikke kun dem, der var relateret til den relevante fil. Det bet\u00f8d, at et klik p\u00e5 knappen i Firefox kunne initiere skrivning af megabyte data til den magnetiske disk, hvilket kunne tage mange sekunder. Problemet blev l\u00f8st, som jeg forstod det fra denne<\/a><\/noindex> materialet, ved at flytte arbejdet med databasen til asynkrone baggrundsopgaver. Det betyder, at tidligere i Firefox var der implementeret strengere krav til datalagringsimulering, end hvad der egentlig var n\u00f8dvendigt, og egenskaberne ved filsystemet ext3 forv\u00e6rrede blot dette problem.<\/p>\n

Det andet problem opstod i 2009. Dengang, efter et systemnedbrud, st\u00f8dte brugerne af det nye filsystem ext4 p\u00e5, at mange nyligt oprettede filer havde nul l\u00e6ngde, mens det ikke skete med det \u00e6ldre filsystem ext3. I den foreg\u00e5ende s\u00e6tning n\u00e6vnte jeg, at ext3 skrev for meget data til disken, hvilket bremse fsync()<\/code>. For at forbedre situationen skriver ext4 kun de \"beskidte\" sider tilbage til disken, der er relateret til en specifik fil. Data fra andre filer forbliver i hukommelsen i meget l\u00e6ngere tid end med brug af ext3. Dette blev gjort for at forbedre ydeevnen (som standard forbliver data i denne tilstand i 30 sekunder, dette kan justeres ved hj\u00e6lp af dirty_expire_centisecs<\/a><\/noindex>; her<\/a><\/noindex> , hvor du kan finde yderligere oplysninger om dette). Det betyder, at et stort antal data kan g\u00e5 tabt permanent efter et nedbrud. L\u00f8sningen p\u00e5 dette problem ligger i brugen af fsync()<\/code> i applikationer, der skal sikre vedvarende datalagring og maksimalt beskytte dem mod konsekvenserne af nedbrud. Funktionen fsync()<\/code> fungerer langt mere effektivt med ext4 end med ext3. Ulempen ved denne tilgang er, at dens anvendelse, som f\u00f8r, bremser udf\u00f8relsen af visse operationer, s\u00e5som installation af programmer. Se detaljer om dette her<\/a><\/noindex> og her<\/a><\/noindex>.<\/p>\n

Det tredje problem, der ang\u00e5r fsync()<\/code>, opstod i 2018. Dengang, inden for rammerne af PostgreSQL-projektet, blev det afsl\u00f8ret, at hvis funktionen fsync()<\/code> st\u00f8der p\u00e5 en fejl, markerer den \"beskidte\" sider som \"rene\". Som et resultat vil de efterf\u00f8lgende kald fsync()<\/code> der bliver ikke gjort noget med s\u00e5danne sider. P\u00e5 grund af dette gemmes de modificerede sider i hukommelsen og skrives aldrig til disken. Dette er en reel katastrofe, da applikationen vil tro, at nogle data er gemt p\u00e5 disken, n\u00e5r det i virkeligheden ikke er tilf\u00e6ldet. S\u00e5danne fejl fsync()<\/code> forekommer sj\u00e6ldent, og applikationen kan i s\u00e5danne situationer n\u00e6sten intet g\u00f8re for at bek\u00e6mpe problemet. I dag, n\u00e5r dette sker, afslutter PostgreSQL og andre applikationer ofte ned. Her<\/a><\/noindex>, i materialet \"Kan applikationer komme sig efter fsync-fejl?\" bliver dette problem udforsket i detaljer. I \u00f8jeblikket er den bedste l\u00f8sning p\u00e5 dette problem at bruge Direct I\/O med flaget O_SYNC<\/code> eller med flaget O_DSYNC<\/code>. Med denne tilgang vil systemet rapportere fejl, der kan opst\u00e5 under specifikke data skriveoperationer, men denne tilgang kr\u00e6ver, at applikationen selv h\u00e5ndterer buffere. L\u00e6s mere om dette her<\/a><\/noindex> og her<\/a><\/noindex>.<\/p>\n

\u00c5bning af filer med flagene O_SYNC og O_DSYNC<\/h2>\n

\nLad os vende tilbage til diskussionen om de mekanismer, der muligg\u00f8r holdbar datalagring i Linux. Det handler specifikt om at bruge flaget O_SYNC<\/code> eller flaget O_DSYNC<\/code> ved \u00e5bning af filer ved hj\u00e6lp af systemopkald open()<\/a><\/noindex>. Med denne tilgang udf\u00f8res hver data skriveoperation, som om hver kommando write()<\/code> systemet gives, henholdsvis kommandoer fsync()<\/code> og fdatasync()<\/code>. I POSIX specifikation<\/a><\/noindex> kaldes \"Synchronized I\/O File Integrity Completion\" og \"Data Integrity Completion\". Den prim\u00e6re fordel ved denne tilgang er, at der kun er behov for at udf\u00f8re \u00e9t systemopkald for at sikre dataintegritet, og ikke to (f.eks. - write()<\/code> og fdatasync()<\/code>). Den st\u00f8rste ulempe ved denne tilgang er, at alle skriveoperationer, der bruger den relevante filbeskriver, vil v\u00e6re synkroniserede, hvilket kan begr\u00e6nse mulighederne for struktureret kode i applikationen.<\/p>\n

Brugen af Direct I\/O med flaget O_DIRECT<\/h2>\n

\nSystemopkald open()<\/code> underst\u00f8tter flaget O_DIRECT<\/code>, som er beregnet til at udf\u00f8re input-output operationer ved at omg\u00e5 operativsystemets cache og interagere direkte med disken. Dette betyder i mange tilf\u00e6lde, at skrivekommandoerne, der gives af programmet, vil blive direkte oversat til kommandoer, der er rettet mod diskoperationer. Men generelt er denne mekanisme ikke en erstatning for funktionerne fsync()<\/code> eller fdatasync()<\/code>. Problemet er, at selve disken kan udskyde eller cache<\/a><\/noindex> de relevante dataskrivekommandoer. Og hvad der er v\u00e6rre, i nogle s\u00e6rlige tilf\u00e6lde vil input-output-operationer, der udf\u00f8res med flaget O_DIRECT<\/code>, blive translateret<\/a><\/noindex> til traditionelle bufferede operationer. Den nemmeste m\u00e5de at l\u00f8se dette problem p\u00e5 er at bruge et flag, n\u00e5r man \u00e5bner filer O_DSYNC<\/code>, hvilket vil betyde, at hver skrivingoperation vil blive efterfulgt af et kald fdatasync()<\/code>.<\/p>\n

Det viser sig, at der for nylig er blevet tilf\u00f8jet en 'hurtig vej' til filsystemet XFS for O_DIRECT|O_DSYNC<\/code>-skrivning af data. Hvis blokken skrives over ved hj\u00e6lp af O_DIRECT|O_DSYNC<\/code>, s\u00e5 vil XFS, i stedet for at t\u00f8mme cachen, udf\u00f8re FUA-skrivningskommandoen, hvis enheden underst\u00f8tter det. Jeg bekr\u00e6ftede dette ved hj\u00e6lp af v\u00e6rkt\u00f8jet blktrace<\/code> i Linux 5.4\/Ubuntu 20.04. Denne tilgang b\u00f8r v\u00e6re mere effektiv, da den minimalt skriver data til disken og samtidig anvender \u00e9n operation i stedet for to (skrivning og t\u00f8mning af cache). Jeg fandt et link til patch<\/a><\/noindex> kernen fra 2018, hvor denne mekanisme er implementeret. Der er en diskussion om anvendelse af denne optimering i andre filsystemer, men s\u00e5 vidt jeg ved, er XFS det eneste filsystem, der underst\u00f8tter det indtil videre.<\/p>\n

Funktionen sync_file_range()<\/h2>\n

\nI Linux er der et systemopkald sync_file_range()<\/a><\/noindex>, som g\u00f8r det muligt at t\u00f8mme kun en del af en fil til disken, ikke hele filen. Dette opkald initierer en asynkron t\u00f8mning af data og venter ikke p\u00e5, at det er afsluttet. Men i dokumentationen til sync_file_range()<\/code> siges det, at denne kommando er 'meget farlig'. Det anbefales ikke at bruge den. Egenskaberne og farerne sync_file_range()<\/code> er meget godt beskrevet i denne<\/a><\/noindex> materialet. Is\u00e6r ser det ud til, at dette opkald bruger RocksDB til at styre, hvorn\u00e5r kernen t\u00f8mmer 'beskidte' data til disken. Men samtidig bruges fdatasync()<\/code>. I koden<\/a><\/noindex> RocksDB har interessante kommentarer om dette emne. For eksempel ser det ud til, at opkaldet sync_file_range()<\/code> ikke f\u00f8rer til t\u00f8mning af data til disken, n\u00e5r ZFS anvendes. Erfaring fort\u00e6ller mig, at kode, der sj\u00e6ldent benyttes, m\u00e5ske indeholder fejl. Derfor ville jeg r\u00e5de imod at bruge dette systemopkald uden en ekstrem n\u00f8dvendighed.<\/p>\n

Systemopkald, der hj\u00e6lper med at sikre holdbar datalagring<\/h2>\n

\nJeg er kommet frem til, at man til udf\u00f8relse af ind- og udt\u00e6gningsoperationer, der sikrer vedvarende datalagring, kan benytte tre metoder. Alle kr\u00e6ver et funktionskald fsync()<\/code> for den mappe, hvor filen er oprettet. Her er disse metoder:<\/p>\n

    \n
  1. Kald af funktionen fdatasync()<\/code> eller fsync()<\/code> efter funktionen write()<\/code> (det er bedre at benytte fdatasync()<\/code>).<\/li>\n
  2. Arbejdet med filbeskrivere, der er \u00e5bnet med flaget O_DSYNC<\/code> eller O_SYNC<\/code> (bedre \u2014 med flaget O_DSYNC<\/code>).<\/li>\n
  3. Brug af kommandoen pwritev2()<\/code> med flag RWF_DSYNC<\/code> eller RWF_SYNC<\/code> (fortrinsvis \u2014 med flaget RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Noter om ydeevne<\/h2>\n

    \nJeg har ikke udf\u00f8rt grundige m\u00e5linger af ydeevnen for de forskellige mekanismer, jeg har unders\u00f8gt. De hastighedsforskelle, jeg har bem\u00e6rket, er ret sm\u00e5. Det betyder, at jeg kan tage fejl, og at det samme i andre omst\u00e6ndigheder kan vise andre resultater. F\u00f8rst vil jeg tale om, hvad der har den st\u00f8rste indflydelse p\u00e5 ydeevnen, og derefter, hvad der har mindre indflydelse p\u00e5 ydeevnen.<\/p>\n

      \n
    1. Oprettelse af data i en fil er hurtigere end at tilf\u00f8je data til filen (ydelsesgevinsten kan v\u00e6re 2-100%). At tilf\u00f8je data til en fil kr\u00e6ver yderligere \u00e6ndringer i filens metadata, selv efter systemkaldet fallocate()<\/code>, men omfanget af denne effekt kan variere. Jeg anbefaler, at man for at sikre den bedste ydeevne kalder fallocate()<\/code> til at forudallokere det n\u00f8dvendige plads. Derefter skal dette rum eksplicit fyldes med nuller og kaldes fsync()<\/code>. Dette g\u00f8r, at de relevante blokke i filsystemet bliver markeret som \"allokerede\", og ikke som \"ikke-allokerede\". Dette giver en lille (ca. 2%) forbedring af ydeevnen. Desuden kan det hos nogle diske tage l\u00e6ngere tid at f\u00e5 adgang til blokkerne som f\u00f8rste operation i forhold til andre. Det betyder, at udfyldning af rummet med nuller kan f\u00f8re til en betydelig (ca. 100%) forbedring af ydeevnen. S\u00e6rligt kan dette v\u00e6re g\u00e6ldende for diske AWS EBS<\/a><\/noindex> (dette er uofficielle data, som jeg ikke har kunnet bekr\u00e6fte). Det samme g\u00e6lder for lagre GCP Persistent Disk<\/a><\/noindex> (og dette er allerede officielle oplysninger, bekr\u00e6ftet af test). Andre specialister har gjort de samme observationer<\/a><\/noindex>, der relaterer sig til forskellige diske.<\/li>\n
    2. Jo f\u00e6rre systemkald, desto h\u00f8jere ydeevne (gevinsten kan v\u00e6re omkring 5%). Det ser ud til, at kaldet open()<\/code> med flag O_DSYNC<\/code> eller kaldet pwritev2()<\/code> med flag RWF_SYNC<\/code> er hurtigere end kaldet fdatasync()<\/code>Jeg mist\u00e6nker, at det har noget at g\u00f8re med, at der med denne tilgang er f\u00e6rre systemopkald, der kr\u00e6ves for at l\u00f8se den samme opgave (et opkald i stedet for to). Men forskellen i ydeevnen er meget lille, s\u00e5 du kan fuldst\u00e6ndig ignorere den og bruge det, der ikke vil komplicere logikken i din applikation.<\/li>\n<\/ol>\n

      \nHvis du er interesseret i emnet b\u00e6redygtig datalagring \u2014 her er nogle nyttige materialer:<\/p>\n