{"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\/sv\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"H\u00e5llbar datalagring och fil-API:er f\u00f6r Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jag, medan jag utforskade datalagringens h\u00e5llbarhet i molnsystem, beslutade att testa mig sj\u00e4lv f\u00f6r att s\u00e4kerst\u00e4lla att jag f\u00f6rst\u00e5r de grundl\u00e4ggande sakerna. Jag b\u00f6rjade med att l\u00e4sa specifikationen f\u00f6r NVMe<\/a><\/noindex> f\u00f6r att f\u00f6rst\u00e5 vilka garantier g\u00e4llande h\u00e5llbar datalagring (det vill s\u00e4ga garantier f\u00f6r att data kommer att vara tillg\u00e4ngliga efter systemfel) som NVMe-enheter ger oss. Jag drog f\u00f6ljande grundl\u00e4ggande slutsatser: man m\u00e5ste betrakta data som korrupta fr\u00e5n det \u00f6gonblick kommandot f\u00f6r skrivning av data ges och fram till dess att skrivningen har slutf\u00f6rts p\u00e5 lagringsmediet. Men i de flesta program f\u00f6r dataskrivning anv\u00e4nds utan problem systemanrop.<\/p>\n

I detta material utforskar jag mekanismerna f\u00f6r h\u00e5llbar datalagring som tillhandah\u00e5lls av fil-API:er i Linux. Det verkar som att det hela borde vara enkelt: programmet anropar kommandot write()<\/code>, och efter det att detta kommando har slutf\u00f6rts, ska data vara s\u00e4kert lagrade p\u00e5 disken. Men write()<\/code> kopierar bara applikationens data till k\u00e4rnkashen som ligger i det prim\u00e4ra minnet. F\u00f6r att tvinga systemet att skriva data p\u00e5 disken m\u00e5ste man anv\u00e4nda vissa ytterligare mekanismer.<\/p>\n

\"H\u00e5llbar<\/a><\/noindex><\/p>\n

Sammanfattningsvis utg\u00f6r detta material en samling anteckningar om vad jag har l\u00e4rt mig om det \u00e4mne som intresserar mig. Om man ska kortfattat beskriva det mest viktiga, s\u00e5 inneb\u00e4r det att f\u00f6r att organisera h\u00e5llbar datalagring b\u00f6r man anv\u00e4nda kommandot fdatasync()<\/code> eller \u00f6ppna filer med flaggan O_DSYNC<\/code>. Om du \u00e4r intresserad av att l\u00e4sa mer ing\u00e5ende om vad som h\u00e4nder med data p\u00e5 v\u00e4gen fr\u00e5n programkoden till disken, kika p\u00e5 denna<\/a><\/noindex> artikel.
\n<\/a><\/noindex><\/p>\n

Funktionens write() egenskaper<\/h2>\n

\nSystemanropet write()<\/code> \u00e4r definierat i standarden IEEE POSIX<\/a><\/noindex> som ett f\u00f6rs\u00f6k att skriva data till en filbeskrivare. Efter att operationen har slutf\u00f6rts framg\u00e5ngsrikt ska write()<\/code> l\u00e4soperationer returnera exakt de byte som tidigare har skrivits, \u00e4ven om data beg\u00e4rs fr\u00e5n andra processer eller tr\u00e5dar (h\u00e4r<\/a><\/noindex> den motsvarande delen av POSIX-standarden). H\u00e4r<\/a><\/noindex>, i avsnittet som handlar om interaktionen mellan tr\u00e5dar och vanliga filoperationer, finns en anm\u00e4rkning som s\u00e4ger att om var och en av de tv\u00e5 tr\u00e5darna anropar dessa funktioner, s\u00e5 m\u00e5ste varje anrop se antingen alla de angivna konsekvenser som ett annat anrop medf\u00f6r, eller inte se n\u00e5gra konsekvenser alls. Detta leder till slutsatsen att alla filin- och utdataoperationer m\u00e5ste beh\u00e5lla l\u00e5sning p\u00e5 den resurs de arbetar med.<\/p>\n

Betyder det att operationen write()<\/code> \u00e4r atom\u00e4r? Tekniskt sett \u2014 ja. L\u00e4soperationer ska returnera antingen allt eller inget av det som skrivits med hj\u00e4lp av write()<\/code>. Men operationen write()<\/code>, enligt standarden, beh\u00f6ver inte n\u00f6dv\u00e4ndigtvis slutf\u00f6ras genom att skriva allt som den erbjudits att skriva. Den f\u00e5r utf\u00f6ra skrivning av endast en del av data. Till exempel kan vi ha tv\u00e5 tr\u00e5dar, var och en av dem l\u00e4gger till 1024 byte till en fil som beskrivs av samma filbeskrivare. Ur standardens synvinkel \u00e4r det acceptabelt att resultatet \u00e4r att varje skrivoperation kan justera filen med endast ett byte. Dessa operationer f\u00f6rblir atom\u00e4ra, men efter att de \u00e4r f\u00e4rdiga, kommer de data som skrivits av dem i filen att vara blandade. H\u00e4r \u00e4r<\/a><\/noindex> en mycket intressant diskussion om detta p\u00e5 Stack Overflow.<\/p>\n

Funktionerna fsync() och fdatasync()<\/h2>\n

\nDet enklaste s\u00e4ttet att skriva data till disken \u00e4r att anropa funktionen fsync()<\/a><\/noindex>. Denna funktion beg\u00e4r av operativsystemet att \u00f6verf\u00f6ra alla modifierade block fr\u00e5n cachen till disken. Detta inkluderar alla filmetadata (\u00e5tkomsttid, \u00e4ndringstid f\u00f6r filen och s\u00e5 vidare). Jag anser att behovet av dessa metadata s\u00e4llan uppst\u00e5r, s\u00e5 om du vet att de inte \u00e4r viktiga f\u00f6r dig, kan du anv\u00e4nda funktionen fdatasync()<\/code>. I hj\u00e4lpen<\/a><\/noindex> per fdatasync()<\/code> anger att under k\u00f6rningen av denna funktion sparas en m\u00e4ngd metadata till disken som \"\u00e4r n\u00f6dv\u00e4ndig f\u00f6r korrekt utf\u00f6rande av n\u00e4sta datal\u00e4sningsoperationer\". Och detta \u00e4r precis vad de flesta applikationer bryr sig om.<\/p>\n

Ett av problemen som kan uppst\u00e5 h\u00e4r \u00e4r att dessa mekanismer inte garanterar att filen kan uppt\u00e4ckas efter en eventuell krasch. Specifikt, n\u00e4r en ny fil skapas, m\u00e5ste man anropa fsync()<\/code> f\u00f6r katalogen som den inneh\u00e5ller. Annars kan det efter ett fel bli s\u00e5 att denna fil inte finns. Anledningen till detta \u00e4r att i UNIX, p\u00e5 grund av anv\u00e4ndning av h\u00e5rda l\u00e4nkar, kan filen existera i flera kataloger. D\u00e4rf\u00f6r, vid anropet fsync()<\/code> kan filen inte veta vilken specifik katalog som ocks\u00e5 ska skrivas till disken (). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex> om detta kan man l\u00e4sa mer). Det verkar som att filsystemet ext4 har f\u00f6rm\u00e5gan automatiskt<\/a><\/noindex> att till\u00e4mpa fsync()<\/code> till kataloger som inneh\u00e5ller motsvarande filer, men i fallet med andra filsystem kan det vara annorlunda.<\/p>\n

Denna mekanism kan implementeras p\u00e5 olika s\u00e4tt i olika filsystem. Jag anv\u00e4nde blktrace<\/a><\/noindex> f\u00f6r att f\u00e5 veta vilka diskoperationer som anv\u00e4nds i filsystemen ext4 och XFS. B\u00e5da ger vanliga skrivkommandon till disken b\u00e5de f\u00f6r filinneh\u00e5ll och f\u00f6r filsystemets logg, skriver ut cachen och avslutar operationen med en FUA-skrivning (Force Unit Access, data skrivs direkt till disken, f\u00f6rbi cachen) i loggen. Sannolikt g\u00f6r de s\u00e5 f\u00f6r att bekr\u00e4fta att operationen \u00e4gde rum. P\u00e5 diskar som inte st\u00f6djer FUA orsakar detta tv\u00e5 cache-skrivningar. Mina experiment visade att fdatasync()<\/code> \u00e4r n\u00e5got snabbare fsync()<\/code>. Verktyget blktrace<\/code> indikerar att fdatasync()<\/code> vanligtvis skriver mindre data till disken (i ext4 fsync()<\/code> skriver 20 KiB, medan fdatasync()<\/code> \u2013 16 KiB). Dessutom uppt\u00e4ckte jag att XFS \u00e4r n\u00e5got snabbare \u00e4n ext4. Och d\u00e4r lyckades blktrace<\/code> f\u00e5 veta att fdatasync()<\/code> skriver mindre data till disken (4 KiB i XFS).<\/p>\n

Otydliga situationer som uppst\u00e5r vid anv\u00e4ndning av fsync()<\/h2>\n

\nJag kan minnas tre otydliga situationer som handlar om fsync()<\/code>, som jag st\u00f6tt p\u00e5 i praktiken.<\/p>\n

Det f\u00f6rsta tillf\u00e4llet intr\u00e4ffade 2008. D\u00e5 \u201dfr\u00f6s\u201d Firefox 3:s gr\u00e4nssnitt om man skrev till disken med ett stort antal filer. Problemet var att i implementeringen av gr\u00e4nssnittet f\u00f6r att lagra information om dess tillst\u00e5nd anv\u00e4ndes en SQLite-databas. Efter varje f\u00f6r\u00e4ndring som \u00e4gde rum i gr\u00e4nssnittet anropades funktionen fsync()<\/code>, vilket gav bra garantier f\u00f6r h\u00e5llbar datalagring. I det filsystem som anv\u00e4ndes d\u00e5, ext3, funktionen fsync()<\/code> s\u00e4nde alla \"smutsiga\" sidor till disken i systemet, och inte bara de som hade att g\u00f6ra med den aktuella filen. Det innebar att ett klick p\u00e5 knappen i Firefox kunde initiera skrivning av megabyte data p\u00e5 den magnetiska disken, vilket kunde ta m\u00e5nga sekunder. L\u00f6sningen p\u00e5 problemet, s\u00e5 l\u00e5ngt jag f\u00f6rstod utifr\u00e5n detta<\/a><\/noindex> materialet, var att flytta databashanteringen till asynkrona bakgrundsuppgifter. Det betyder att det tidigare i Firefox fanns str\u00e4ngare krav p\u00e5 datalagringens motst\u00e5ndskraft \u00e4n vad som faktiskt var n\u00f6dv\u00e4ndigt, och egenskaperna hos filsystemet ext3 f\u00f6rv\u00e4rrade bara detta problem.<\/p>\n

Det andra problemet intr\u00e4ffade 2009. Efter en systemkrasch st\u00f6tte anv\u00e4ndare av det nya filsystemet ext4 p\u00e5 att m\u00e5nga nyligen skapade filer hade en noll l\u00e4ngd, medan s\u00e5dana problem inte intr\u00e4ffade med det \u00e4ldre filsystemet ext3. I det f\u00f6reg\u00e5ende stycket n\u00e4mnde jag att ext3 s\u00e4nde f\u00f6r mycket data till disken, vilket kraftigt f\u00f6rs\u00e4mrade prestandan. fsync()<\/code>F\u00f6r att f\u00f6rb\u00e4ttra situationen s\u00e4nder ext4 endast de \"smutsiga\" sidorna som har att g\u00f6ra med den specifika filen till disken. Data fr\u00e5n andra filer stannar kvar i minnet under en mycket l\u00e4ngre tid \u00e4n n\u00e4r ext3 anv\u00e4nds. Detta gjordes f\u00f6r att f\u00f6rb\u00e4ttra prestanda (som standard f\u00f6rblir data i detta tillst\u00e5nd i 30 sekunder, och detta kan justeras med hj\u00e4lp av dirty_expire_centisecs<\/a><\/noindex>; ). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex> som kan hittas i ytterligare material om detta). Det inneb\u00e4r att en stor m\u00e4ngd data kan g\u00e5 f\u00f6rlorad efter en krasch. L\u00f6sningen p\u00e5 detta problem handlar om anv\u00e4ndning av fsync()<\/code> i applikationer som beh\u00f6ver s\u00e4kerst\u00e4lla motst\u00e5ndskraftig datalagring och maximalt skydda den mot konsekvenserna av krasch. Funktionen fsync()<\/code> \u00e4r mycket effektivare vid anv\u00e4ndning av ext4 \u00e4n vid anv\u00e4ndning av ext3. Nackdelen med detta tillv\u00e4gag\u00e5ngss\u00e4tt \u00e4r att dess till\u00e4mpning, liksom tidigare, saktar ner genomf\u00f6randet av vissa operationer, som installation av program. Mer information om detta finns i h\u00e4r<\/a><\/noindex> och h\u00e4r<\/a><\/noindex>.<\/p>\n

Det tredje problemet, som r\u00f6r fsync()<\/code>, intr\u00e4ffade 2018. Inom ramen f\u00f6r PostgreSQL-projektet fick man reda p\u00e5 att om funktionen fsync()<\/code> st\u00f6ter p\u00e5 ett fel, markerar den \"smutsiga\" sidor som \"rena\". Som ett resultat markerar f\u00f6ljande anrop fsync()<\/code> Inga \u00e5tg\u00e4rder vidtas med s\u00e5dana sidor. P\u00e5 grund av detta lagras modifierade sidor i minnet och skrivs aldrig till disken. Detta \u00e4r en riktig katastrof, eftersom applikationen kommer att tro att vissa data har skrivits till disken, n\u00e4r de i sj\u00e4lva verket inte har det. S\u00e5dana fel fsync()<\/code> \u00e4r s\u00e4llsynta, applikationen kan n\u00e4stan inte g\u00f6ra n\u00e5got f\u00f6r att hantera problemet i s\u00e5dana situationer. Numera, n\u00e4r detta intr\u00e4ffar, kraschar PostgreSQL och andra applikationer. H\u00e4r<\/a><\/noindex>, i materialet \u00abKan applikationer \u00e5terh\u00e4mta sig fr\u00e5n fsync-fel?\u00bb, unders\u00f6ks detta problem i detalj. F\u00f6r n\u00e4rvarande \u00e4r den b\u00e4sta l\u00f6sningen p\u00e5 detta problem att anv\u00e4nda Direct I\/O med flaggan O_SYNC<\/code> eller med flaggan O_DSYNC<\/code>. Med denna metod rapporterar systemet om fel som kan uppst\u00e5 vid specifika dataskrivningsoperationer, men denna metod kr\u00e4ver att applikationen hanterar sina egna buffertar. L\u00e4s mer om detta h\u00e4r<\/a><\/noindex> och h\u00e4r<\/a><\/noindex>.<\/p>\n

\u00d6ppna filer med hj\u00e4lp av flaggorna O_SYNC och O_DSYNC<\/h2>\n

\nL\u00e5t oss \u00e5terv\u00e4nda till diskussionen om Linux-mekanismer som s\u00e4kerst\u00e4ller h\u00e5llbar datalagring. N\u00e4mligen handlar det om att anv\u00e4nda flaggan O_SYNC<\/code> eller flaggan O_DSYNC<\/code> vid \u00f6ppning av filer med hj\u00e4lp av systemanropet open()<\/a><\/noindex>. Med denna metod utf\u00f6rs varje dataskrivningsoperation som om systemet efter varje kommando ger motsvarande instruktioner write()<\/code> enligt POSIX-specifikationerna fsync()<\/code> och fdatasync()<\/code>. I detta kallas \u00abSynchronized I\/O File Integrity Completion\u00bb och \u00abData Integrity Completion\u00bb. Den fr\u00e4msta f\u00f6rdelen med denna metod \u00e4r att f\u00f6r att s\u00e4kerst\u00e4lla dataintegritet beh\u00f6ver bara ett systemanrop g\u00f6ras, inte tv\u00e5 (till exempel \u2014<\/a><\/noindex> ). Huvudnackdelen med denna metod \u00e4r att alla skrivoperationer som anv\u00e4nder den relevanta filbeskrivaren kommer att synkroniseras, vilket kan begr\u00e4nsa m\u00f6jligheterna att strukturera applikationskoden. write()<\/code> och fdatasync()<\/code>Anv\u00e4ndning av Direct I\/O med flaggan O_DIRECT<\/p>\n

st\u00f6djer flaggan<\/h2>\n

\nSystemanropet open()<\/code> O_DIRECT , som \u00e4r avsedd att, genom att kringg\u00e5 operativsystemets cache, utf\u00f6ra in- och utdataoperationer genom att interagera direkt med disken. Detta inneb\u00e4r i m\u00e5nga fall att skrivkommandon som utf\u00e4rdas av programmet direkt \u00f6vers\u00e4tts till kommandon som riktas till disken. Men i allm\u00e4nhet \u00e4r denna mekanism inte en ers\u00e4ttning f\u00f6r funktioner<\/code>. Det handlar om att sj\u00e4lva disken kan fsync()<\/code> eller fdatasync()<\/code>skjuta upp eller cacha skjuta upp eller cachelagra<\/a><\/noindex> relevanta dataskriverkommandon. Och v\u00e4rre \u00e4n s\u00e5, i vissa s\u00e4rskilda fall kan I\/O-operationer som utf\u00f6rs med flaggan , som \u00e4r avsedd att, genom att kringg\u00e5 operativsystemets cache, utf\u00f6ra in- och utdataoperationer genom att interagera direkt med disken. Detta inneb\u00e4r i m\u00e5nga fall att skrivkommandon som utf\u00e4rdas av programmet direkt \u00f6vers\u00e4tts till kommandon som riktas till disken. Men i allm\u00e4nhet \u00e4r denna mekanism inte en ers\u00e4ttning f\u00f6r funktioner<\/code>, \u00f6vers\u00e4tts<\/a><\/noindex> till traditionella buffrade operationer. Det enklaste s\u00e4ttet att l\u00f6sa detta problem \u00e4r att anv\u00e4nda en flagga f\u00f6r att \u00f6ppna filer O_DSYNC<\/code>, vilket kommer att inneb\u00e4ra att varje skrivoperation f\u00f6ljs av ett samtal fdatasync()<\/code>.<\/p>\n

Det visade sig att ett \"snabbt s\u00e4tt\" nyligen har lagts till i XFS-filsystemet f\u00f6r O_DIRECT|O_DSYNC<\/code>-dataskrivningar. Om en block skrivs \u00f6ver med hj\u00e4lp av O_DIRECT|O_DSYNC<\/code>, s\u00e5 kommer XFS, ist\u00e4llet f\u00f6r att spola cachen, att utf\u00f6ra FUA-skrivkommandot om enheten st\u00f6djer det. Jag bekr\u00e4ftade detta genom att anv\u00e4nda verktyget blktrace<\/code> i Linux 5.4\/Ubuntu 20.04. Denna metod b\u00f6r vara effektivare, eftersom den skriver ett minimum av data till disken och endast utf\u00f6r en operation i st\u00e4llet f\u00f6r tv\u00e5 (skrivning och spola cachen). Jag fann en l\u00e4nk till patch<\/a><\/noindex> k\u00e4rnan fr\u00e5n 2018 d\u00e4r denna mekanism \u00e4r implementerad. D\u00e4r finns en diskussion som handlar om till\u00e4mpningen av denna optimering i andra filsystem, men s\u00e5vitt jag vet \u00e4r XFS det enda filsystemet som st\u00f6djer detta hittills.<\/p>\n

funktionen sync_file_range()<\/h2>\n

\nI Linux finns det ett systemanrop sync_file_range()<\/a><\/noindex>, som till\u00e5ter att endast en del av en fil spolas till disken, inte hela filen. Detta anrop initierar en asynkron avskrivning av data och v\u00e4ntar inte p\u00e5 dess slutf\u00f6rande. Men i dokumentationen f\u00f6r sync_file_range()<\/code> n\u00e4mns det att detta kommando \u00e4r \"mycket farligt\". Det rekommenderas inte att anv\u00e4nda det. Funktionerna och farorna sync_file_range()<\/code> \u00e4r mycket v\u00e4l beskrivna i detta<\/a><\/noindex> materialet. S\u00e4rskilt verkar det som att detta anrop anv\u00e4nder RocksDB f\u00f6r att hantera n\u00e4r k\u00e4rnan spolar \"smutsiga\" data till disken. Men d\u00e4r anv\u00e4nds ocks\u00e5 fdatasync()<\/code>. I koden<\/a><\/noindex> RocksDB har intressanta kommentarer om detta \u00e4mne. Till exempel verkar det som att anropet sync_file_range()<\/code> vid anv\u00e4ndning av ZFS inte leder till att data spolas till disken. Min erfarenhet s\u00e4ger mig att kod som s\u00e4llan anv\u00e4nds kan inneh\u00e5lla buggar. D\u00e4rf\u00f6r skulle jag r\u00e5da dig att inte anv\u00e4nda detta systemanrop utan absolut n\u00f6dv\u00e4ndighet.<\/p>\n

Systemanrop som hj\u00e4lper till att s\u00e4kerst\u00e4lla h\u00e5llbar datalagring<\/h2>\n

\nJag har kommit fram till att det finns tre tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r att utf\u00f6ra in- och utdataoperationer som s\u00e4kerst\u00e4ller stabil lagring av data. Alla kr\u00e4ver att man anropar en funktion fsync()<\/code> f\u00f6r katalogen d\u00e4r filen skapades. H\u00e4r \u00e4r dessa tillv\u00e4gag\u00e5ngss\u00e4tt:<\/p>\n

    \n
  1. Anrop av funktionen fdatasync()<\/code> eller fsync()<\/code> efter funktionen write()<\/code> (b\u00e4st att anv\u00e4nda fdatasync()<\/code>).<\/li>\n
  2. Arbete med en filbeskrivare som \u00f6ppnats med flaggan O_DSYNC<\/code> eller O_SYNC<\/code> (b\u00e4st \u2014 med flaggan O_DSYNC<\/code>).<\/li>\n
  3. Anv\u00e4nda kommandot pwritev2()<\/code> med flaggan RWF_DSYNC<\/code> eller RWF_SYNC<\/code> (f\u00f6redrar \u2014 med flaggan RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Prestandanoteringar<\/h2>\n

    \nJag har inte utf\u00f6rt noggranna m\u00e4tningar av prestandan f\u00f6r de olika mekanismer jag har unders\u00f6kt. De skillnader jag har observerat i hastighet \u00e4r ganska sm\u00e5. Det betyder att jag kan ha fel, och att samma sak kan ge andra resultat under andra f\u00f6rh\u00e5llanden. F\u00f6rst kommer jag att ber\u00e4tta om vad som har st\u00f6rst p\u00e5verkan p\u00e5 prestandan, och sedan om vad som p\u00e5verkar prestandan mindre.<\/p>\n

      \n
    1. \u00d6verskrivning av filens data \u00e4r snabbare \u00e4n att bifoga data till filen (prestandavinsten kan vara 2-100%). Att bifoga data till filen kr\u00e4ver ytterligare \u00e4ndringar i filens metadata, \u00e4ven efter systemanropet fallocate()<\/code>, men omfattningen av denna effekt kan variera. Jag rekommenderar att man anropar fallocate()<\/code> f\u00f6r att f\u00f6rhandsallokera n\u00f6dv\u00e4ndigt utrymme. Sedan m\u00e5ste detta utrymme explicit fyllas med nollor och anropas fsync()<\/code>. Tack vare detta kommer motsvarande block i filsystemet att m\u00e4rkas som \"allokerade\" ist\u00e4llet f\u00f6r \"icke-allokerade\". Detta ger en liten (ungef\u00e4r 2%) f\u00f6rb\u00e4ttring av prestandan. Dessutom kan den f\u00f6rsta \u00e5tkomstoperationen till en block p\u00e5 vissa diskar ta l\u00e4ngre tid \u00e4n andra. Det betyder att fyllning av utrymme med nollor kan leda till ett betydande (ungef\u00e4r 100%) f\u00f6rb\u00e4ttring av prestandan. Speciellt kan detta intr\u00e4ffa med diskar AWS EBS<\/a><\/noindex> (detta \u00e4r icke-officiell data, jag kunde inte bekr\u00e4fta det). Detsamma g\u00e4ller lagringarna GCP Persistent Disk<\/a><\/noindex> (och detta \u00e4r redan officiell information, bekr\u00e4ftad genom tester). Andra experter har gjort liknande observationer<\/a><\/noindex>, relaterade till olika diskar.<\/li>\n
    2. Ju f\u00e4rre systemanrop, desto h\u00f6gre prestanda (vinsten kan vara omkring 5%). Det verkar som att anropet open()<\/code> med flaggan O_DSYNC<\/code> eller anropet pwritev2()<\/code> med flaggan RWF_SYNC<\/code> snabbare anrop fdatasync()<\/code>. Jag misst\u00e4nker att det handlar om att f\u00e4rre systemanrop kr\u00e4vs f\u00f6r att l\u00f6sa samma uppgift (ett anrop ist\u00e4llet f\u00f6r tv\u00e5). Men skillnaden i prestanda \u00e4r mycket liten, s\u00e5 du kan helt enkelt ignorera den och anv\u00e4nda det som inte f\u00f6rsv\u00e5rar logiken i din applikation.<\/li>\n<\/ol>\n

      \nOm du \u00e4r intresserad av \u00e4mnet h\u00e5llbar datalagring - h\u00e4r \u00e4r n\u00e5gra anv\u00e4ndbara material:<\/p>\n