Hållbar datalagring och fil-API:er för Linux

Jag, medan jag utforskade datalagringens hållbarhet i molnsystem, beslutade att testa mig själv för att säkerställa att jag förstår de grundläggande sakerna. Jag började med att läsa specifikationen för NVMe för att förstå vilka garantier gällande hållbar datalagring (det vill säga garantier för att data kommer att vara tillgängliga efter systemfel) som NVMe-enheter ger oss. Jag drog följande grundläggande slutsatser: man måste betrakta data som korrupta från det ögonblick kommandot för skrivning av data ges och fram till dess att skrivningen har slutförts på lagringsmediet. Men i de flesta program för dataskrivning används utan problem systemanrop.

I detta material utforskar jag mekanismerna för hållbar datalagring som tillhandahålls av fil-API:er i Linux. Det verkar som att det hela borde vara enkelt: programmet anropar kommandot write(), och efter det att detta kommando har slutförts, ska data vara säkert lagrade på disken. Men write() kopierar bara applikationens data till kärnkashen som ligger i det primära minnet. För att tvinga systemet att skriva data på disken måste man använda vissa ytterligare mekanismer.

Sammanfattningsvis utgör detta material en samling anteckningar om vad jag har lärt mig om det ämne som intresserar mig. Om man ska kortfattat beskriva det mest viktiga, så innebär det att för att organisera hållbar datalagring bör man använda kommandot fdatasync() eller öppna filer med flaggan O_DSYNC. Om du är intresserad av att läsa mer ingående om vad som händer med data på vägen från programkoden till disken, kika på denna artikel.

Funktionens write() egenskaper

Systemanropet write() är definierat i standarden IEEE POSIX som ett försök att skriva data till en filbeskrivare. Efter att operationen har slutförts framgångsrikt ska write() läsoperationer returnera exakt de byte som tidigare har skrivits, även om data begärs från andra processer eller trådar (här den motsvarande delen av POSIX-standarden). Här, i avsnittet som handlar om interaktionen mellan trådar och vanliga filoperationer, finns en anmärkning som säger att om var och en av de två trådarna anropar dessa funktioner, så måste varje anrop se antingen alla de angivna konsekvenser som ett annat anrop medför, eller inte se några konsekvenser alls. Detta leder till slutsatsen att alla filin- och utdataoperationer måste behålla låsning på den resurs de arbetar med.

Betyder det att operationen write() är atomär? Tekniskt sett — ja. Läsoperationer ska returnera antingen allt eller inget av det som skrivits med hjälp av write(). Men operationen write(), enligt standarden, behöver inte nödvändigtvis slutföras genom att skriva allt som den erbjudits att skriva. Den får utföra skrivning av endast en del av data. Till exempel kan vi ha två trådar, var och en av dem lägger till 1024 byte till en fil som beskrivs av samma filbeskrivare. Ur standardens synvinkel är det acceptabelt att resultatet är att varje skrivoperation kan justera filen med endast ett byte. Dessa operationer förblir atomära, men efter att de är färdiga, kommer de data som skrivits av dem i filen att vara blandade. Här är en mycket intressant diskussion om detta på Stack Overflow.

Funktionerna fsync() och fdatasync()

Det enklaste sättet att skriva data till disken är att anropa funktionen fsync(). Denna funktion begär av operativsystemet att överföra alla modifierade block från cachen till disken. Detta inkluderar alla filmetadata (åtkomsttid, ändringstid för filen och så vidare). Jag anser att behovet av dessa metadata sällan uppstår, så om du vet att de inte är viktiga för dig, kan du använda funktionen fdatasync(). I hjälpen per fdatasync() anger att under körningen av denna funktion sparas en mängd metadata till disken som "är nödvändig för korrekt utförande av nästa dataläsningsoperationer". Och detta är precis vad de flesta applikationer bryr sig om.

Ett av problemen som kan uppstå här är att dessa mekanismer inte garanterar att filen kan upptäckas efter en eventuell krasch. Specifikt, när en ny fil skapas, måste man anropa fsync() för katalogen som den innehåller. Annars kan det efter ett fel bli så att denna fil inte finns. Anledningen till detta är att i UNIX, på grund av användning av hårda länkar, kan filen existera i flera kataloger. Därför, vid anropet fsync() kan filen inte veta vilken specifik katalog som också ska skrivas till disken (). Ett typiskt exempel på användning: om detta kan man läsa mer). Det verkar som att filsystemet ext4 har förmågan automatiskt att tillämpa fsync() till kataloger som innehåller motsvarande filer, men i fallet med andra filsystem kan det vara annorlunda.

Denna mekanism kan implementeras på olika sätt i olika filsystem. Jag använde blktrace för att få veta vilka diskoperationer som används i filsystemen ext4 och XFS. Båda ger vanliga skrivkommandon till disken både för filinnehåll och för filsystemets logg, skriver ut cachen och avslutar operationen med en FUA-skrivning (Force Unit Access, data skrivs direkt till disken, förbi cachen) i loggen. Sannolikt gör de så för att bekräfta att operationen ägde rum. På diskar som inte stödjer FUA orsakar detta två cache-skrivningar. Mina experiment visade att fdatasync() är något snabbare fsync(). Verktyget blktrace indikerar att fdatasync() vanligtvis skriver mindre data till disken (i ext4 fsync() skriver 20 KiB, medan fdatasync() – 16 KiB). Dessutom upptäckte jag att XFS är något snabbare än ext4. Och där lyckades blktrace få veta att fdatasync() skriver mindre data till disken (4 KiB i XFS).

Otydliga situationer som uppstår vid användning av fsync()

Jag kan minnas tre otydliga situationer som handlar om fsync(), som jag stött på i praktiken.

Det första tillfället inträffade 2008. Då ”frös” Firefox 3:s gränssnitt om man skrev till disken med ett stort antal filer. Problemet var att i implementeringen av gränssnittet för att lagra information om dess tillstånd användes en SQLite-databas. Efter varje förändring som ägde rum i gränssnittet anropades funktionen fsync(), vilket gav bra garantier för hållbar datalagring. I det filsystem som användes då, ext3, funktionen fsync() sände alla "smutsiga" sidor till disken i systemet, och inte bara de som hade att göra med den aktuella filen. Det innebar att ett klick på knappen i Firefox kunde initiera skrivning av megabyte data på den magnetiska disken, vilket kunde ta många sekunder. Lösningen på problemet, så långt jag förstod utifrån detta materialet, var att flytta databashanteringen till asynkrona bakgrundsuppgifter. Det betyder att det tidigare i Firefox fanns strängare krav på datalagringens motståndskraft än vad som faktiskt var nödvändigt, och egenskaperna hos filsystemet ext3 förvärrade bara detta problem.

Det andra problemet inträffade 2009. Efter en systemkrasch stötte användare av det nya filsystemet ext4 på att många nyligen skapade filer hade en noll längd, medan sådana problem inte inträffade med det äldre filsystemet ext3. I det föregående stycket nämnde jag att ext3 sände för mycket data till disken, vilket kraftigt försämrade prestandan. fsync()För att förbättra situationen sänder ext4 endast de "smutsiga" sidorna som har att göra med den specifika filen till disken. Data från andra filer stannar kvar i minnet under en mycket längre tid än när ext3 används. Detta gjordes för att förbättra prestanda (som standard förblir data i detta tillstånd i 30 sekunder, och detta kan justeras med hjälp av dirty_expire_centisecs; ). Ett typiskt exempel på användning: som kan hittas i ytterligare material om detta). Det innebär att en stor mängd data kan gå förlorad efter en krasch. Lösningen på detta problem handlar om användning av fsync() i applikationer som behöver säkerställa motståndskraftig datalagring och maximalt skydda den mot konsekvenserna av krasch. Funktionen fsync() är mycket effektivare vid användning av ext4 än vid användning av ext3. Nackdelen med detta tillvägagångssätt är att dess tillämpning, liksom tidigare, saktar ner genomförandet av vissa operationer, som installation av program. Mer information om detta finns i här och här.

Det tredje problemet, som rör fsync(), inträffade 2018. Inom ramen för PostgreSQL-projektet fick man reda på att om funktionen fsync() stöter på ett fel, markerar den "smutsiga" sidor som "rena". Som ett resultat markerar följande anrop fsync() Inga åtgärder vidtas med sådana sidor. På grund av detta lagras modifierade sidor i minnet och skrivs aldrig till disken. Detta är en riktig katastrof, eftersom applikationen kommer att tro att vissa data har skrivits till disken, när de i själva verket inte har det. Sådana fel fsync() är sällsynta, applikationen kan nästan inte göra något för att hantera problemet i sådana situationer. Numera, när detta inträffar, kraschar PostgreSQL och andra applikationer. Här, i materialet «Kan applikationer återhämta sig från fsync-fel?», undersöks detta problem i detalj. För närvarande är den bästa lösningen på detta problem att använda Direct I/O med flaggan O_SYNC eller med flaggan O_DSYNC. Med denna metod rapporterar systemet om fel som kan uppstå vid specifika dataskrivningsoperationer, men denna metod kräver att applikationen hanterar sina egna buffertar. Läs mer om detta här och här.

Öppna filer med hjälp av flaggorna O_SYNC och O_DSYNC

Låt oss återvända till diskussionen om Linux-mekanismer som säkerställer hållbar datalagring. Nämligen handlar det om att använda flaggan O_SYNC eller flaggan O_DSYNC vid öppning av filer med hjälp av systemanropet open(). Med denna metod utförs varje dataskrivningsoperation som om systemet efter varje kommando ger motsvarande instruktioner write() enligt POSIX-specifikationerna fsync() och fdatasync(). I detta kallas «Synchronized I/O File Integrity Completion» och «Data Integrity Completion». Den främsta fördelen med denna metod är att för att säkerställa dataintegritet behöver bara ett systemanrop göras, inte två (till exempel — ). Huvudnackdelen med denna metod är att alla skrivoperationer som använder den relevanta filbeskrivaren kommer att synkroniseras, vilket kan begränsa möjligheterna att strukturera applikationskoden. write() och fdatasync()Användning av Direct I/O med flaggan O_DIRECT

stödjer flaggan

Systemanropet open() O_DIRECT , som är avsedd att, genom att kringgå operativsystemets cache, utföra in- och utdataoperationer genom att interagera direkt med disken. Detta innebär i många fall att skrivkommandon som utfärdas av programmet direkt översätts till kommandon som riktas till disken. Men i allmänhet är denna mekanism inte en ersättning för funktioner. Det handlar om att själva disken kan fsync() eller fdatasync()skjuta upp eller cacha skjuta upp eller cachelagra relevanta dataskriverkommandon. Och värre än så, i vissa särskilda fall kan I/O-operationer som utförs med flaggan , som är avsedd att, genom att kringgå operativsystemets cache, utföra in- och utdataoperationer genom att interagera direkt med disken. Detta innebär i många fall att skrivkommandon som utfärdas av programmet direkt översätts till kommandon som riktas till disken. Men i allmänhet är denna mekanism inte en ersättning för funktioner, översätts till traditionella buffrade operationer. Det enklaste sättet att lösa detta problem är att använda en flagga för att öppna filer O_DSYNC, vilket kommer att innebära att varje skrivoperation följs av ett samtal fdatasync().

Det visade sig att ett "snabbt sätt" nyligen har lagts till i XFS-filsystemet för O_DIRECT|O_DSYNC-dataskrivningar. Om en block skrivs över med hjälp av O_DIRECT|O_DSYNC, så kommer XFS, istället för att spola cachen, att utföra FUA-skrivkommandot om enheten stödjer det. Jag bekräftade detta genom att använda verktyget blktrace i Linux 5.4/Ubuntu 20.04. Denna metod bör vara effektivare, eftersom den skriver ett minimum av data till disken och endast utför en operation i stället för två (skrivning och spola cachen). Jag fann en länk till patch kärnan från 2018 där denna mekanism är implementerad. Där finns en diskussion som handlar om tillämpningen av denna optimering i andra filsystem, men såvitt jag vet är XFS det enda filsystemet som stödjer detta hittills.

funktionen sync_file_range()

I Linux finns det ett systemanrop sync_file_range(), som tillåter att endast en del av en fil spolas till disken, inte hela filen. Detta anrop initierar en asynkron avskrivning av data och väntar inte på dess slutförande. Men i dokumentationen för sync_file_range() nämns det att detta kommando är "mycket farligt". Det rekommenderas inte att använda det. Funktionerna och farorna sync_file_range() är mycket väl beskrivna i detta materialet. Särskilt verkar det som att detta anrop använder RocksDB för att hantera när kärnan spolar "smutsiga" data till disken. Men där används också fdatasync(). I koden RocksDB har intressanta kommentarer om detta ämne. Till exempel verkar det som att anropet sync_file_range() vid användning av ZFS inte leder till att data spolas till disken. Min erfarenhet säger mig att kod som sällan används kan innehålla buggar. Därför skulle jag råda dig att inte använda detta systemanrop utan absolut nödvändighet.

Systemanrop som hjälper till att säkerställa hållbar datalagring

Jag har kommit fram till att det finns tre tillvägagångssätt för att utföra in- och utdataoperationer som säkerställer stabil lagring av data. Alla kräver att man anropar en funktion fsync() för katalogen där filen skapades. Här är dessa tillvägagångssätt:

1. Anrop av funktionen fdatasync() eller fsync() efter funktionen write() (bäst att använda fdatasync()).
2. Arbete med en filbeskrivare som öppnats med flaggan O_DSYNC eller O_SYNC (bäst — med flaggan O_DSYNC).
3. Använda kommandot pwritev2() med flaggan RWF_DSYNC eller RWF_SYNC (föredrar — med flaggan RWF_DSYNC).

Prestandanoteringar

Jag har inte utfört noggranna mätningar av prestandan för de olika mekanismer jag har undersökt. De skillnader jag har observerat i hastighet är ganska små. Det betyder att jag kan ha fel, och att samma sak kan ge andra resultat under andra förhållanden. Först kommer jag att berätta om vad som har störst påverkan på prestandan, och sedan om vad som påverkar prestandan mindre.

1. Överskrivning av filens data är snabbare än att bifoga data till filen (prestandavinsten kan vara 2-100%). Att bifoga data till filen kräver ytterligare ändringar i filens metadata, även efter systemanropet fallocate(), men omfattningen av denna effekt kan variera. Jag rekommenderar att man anropar fallocate() för att förhandsallokera nödvändigt utrymme. Sedan måste detta utrymme explicit fyllas med nollor och anropas fsync(). Tack vare detta kommer motsvarande block i filsystemet att märkas som "allokerade" istället för "icke-allokerade". Detta ger en liten (ungefär 2%) förbättring av prestandan. Dessutom kan den första åtkomstoperationen till en block på vissa diskar ta längre tid än andra. Det betyder att fyllning av utrymme med nollor kan leda till ett betydande (ungefär 100%) förbättring av prestandan. Speciellt kan detta inträffa med diskar AWS EBS (detta är icke-officiell data, jag kunde inte bekräfta det). Detsamma gäller lagringarna GCP Persistent Disk (och detta är redan officiell information, bekräftad genom tester). Andra experter har gjort liknande observationer, relaterade till olika diskar.
2. Ju färre systemanrop, desto högre prestanda (vinsten kan vara omkring 5%). Det verkar som att anropet open() med flaggan O_DSYNC eller anropet pwritev2() med flaggan RWF_SYNC snabbare anrop fdatasync(). Jag misstänker att det handlar om att färre systemanrop krävs för att lösa samma uppgift (ett anrop istället för två). Men skillnaden i prestanda är mycket liten, så du kan helt enkelt ignorera den och använda det som inte försvårar logiken i din applikation.

Om du är intresserad av ämnet hållbar datalagring - här är några användbara material:

• I/O Åtkomstmetoder — en översikt över grunderna för in- och utmatningsmekanismer.
• Säkerställande av att data når disken — en berättelse om vad som händer med data på vägen från applikationen till disken.
• När ska du fsynca den innehållande katalogen — svar på frågan om när fsync() ska tillämpas på kataloger. Om man sammanfattar detta, så ska det göras vid skapandet av en ny fil, och anledningen till denna rekommendation är att det kan finnas många länkar till samma fil i Linux.
• SQL Server på Linux: FUA Interna — här finns en beskrivning av hur hållbar datalagring implementeras i SQL Server på Linux-plattformen. Det görs några intressanta jämförelser mellan systemanrop i Windows och Linux. Jag är nästan säker på att det var tack vare detta material som jag lärde mig om FUA-optimering av XFS.

Har du förlorat data som du trodde var säkert lagrade på disken?

Källa: habr.com