Hur bekräftar en ZFS Intent Log återställning av NAS-skrivningar efter strömavbrott?

En ZFS avsiktslogg återställer bekräftade NAS-skrivningar efter strömavbrott genom att behålla en hållbar post av synkrona operationer som ZFS bekräftade innan deras slutgiltiga datablock committades via den normala transaktionsgruppsvägen.

Efter omstart kan ZFS spela upp dessa loggposter och slutföra de avbrutna operationerna. Detta bevarar lagringslöftena till applikationer, men återställer inte varje asynkron skrivning eller reparerar orelaterad hårdvaru- och filsystemsskada.

Vilket löfte ger en synkron skrivning?

En synkron skrivning ber lagringssystemet att inte rapportera framgång förrän operationen har en hållbar återställningspost. synkrona skrivningar går igenom ZIL så att en klient kan lita på bekräftelsen efter en krasch.

Databaser, NFS-arbetsbelastningar, virtuella maskiner och applikationer som använder fsync kan vara beroende av detta löfte. De avancerar sin egen transaktionsstatus efter att lagringen rapporterat att den nödvändiga skrivningen är säker.

Asynkrona skrivningar följer ett annat löfte. De kan finnas kvar i flyktigt minne tills en senare transaktionsgrupps-commit, så nyligen obekräftade ändringar kan försvinna efter plötsligt strömavbrott utan att bryta mot ett synkront hållbarhetskontrakt.

Hur fungerar ZIL och transaktionsgrupper tillsammans?

ZFS samlar normalt smutsig data i transaktionsgrupper och skriver dem effektivt till huvudpoolen. avsiktsloggen registrerar väntande synkrona operationer som en kortlivad återställningsväg tills den relaterade transaktionsgruppen är säkert committad.

Loggen är inte den permanenta platsen för fildata. När transaktionsgruppen når huvudlagringsträdet behövs inte längre de tidigare avsiktsregistren och deras utrymme kan återanvändas.

Denna separation låter ZFS bevara låg latens och hållbarhet för utvalda skrivningar samtidigt som huvudpoolen organiseras i större, mer effektiva transaktionsgrupps-commits.

Vad händer med avsiktsloggen efter strömavbrott?

När NAS:en startar om importerar ZFS poolen och kontrollerar om bekräftade synkrona operationer inte inkluderades i den senaste bekräftade transaktionsgruppen. Vid behov återuppspelas avsiktsloggen under återställningen.

Återuppspelning utför de loggade operationerna i en ny konsekvent transaktionsgrupp. Processen återställer bekräftade skrivningar utan att applikationer behöver gissa vilka bekräftade transaktioner som gick förlorade.

Återställningsomfånget är medvetet litet eftersom loggen täcker nyligen utförda synkrona operationer, inte hela poolen. ZFS förlitar sig fortfarande på sin bekräftade copy-on-write-träd för det bredare filsystemtillståndet.

Vad förändras när ZIL använder en separat SLOG-enhet?

Varje pool har en avsiktsloggmekanism, men en valfri separat loggenhet flyttar sina hållbara poster bort från de huvudsakliga datavdevsenheterna. En låg-latens SLOG kan förkorta synkroniseringskommittéer när huvudpoolen är långsammare på att beständigt skriva små tvångsskrivningar.

SLOG är inte en allmän skrivcache och läses normalt inte under normal drift. De huvudsakliga transaktionsgrupperna skriver fortfarande den auktoritativa datan till den vanliga poolen.

En snabb SLOG hjälper bara arbetsbelastningar som utför meningsfulla synkrona skrivningar. Medieströmning, vanliga läsningar och mestadels asynkrona filkopior visar kanske liten eller ingen fördel.

Varför är strömavbrottsskydd och latens viktigare än kapacitet?

En avsiktsloggsenhet måste bevara bekräftade poster när systemet förlorar ström. strömavbrottsskydd bevarar SLOG-skrivningar som annars bara skulle finnas i enhetens flyktiga cache.

Bestående latens vid små skrivningar och flush-beteende är viktigare än stor annonserad kapacitet. Den aktiva loggen täcker vanligtvis ett kort fönster av väntande synkrona operationer snarare än att fungera som ett stort långsiktigt datalager.

En långsam eller opålitlig enhet kan göra synkrona skrivningar långsammare eller undergräva hållbarhetslöftet. Konsument-SSD-burstbenchmarkar bevisar inte säker tvångsskrivningsbeteende under ett strömavbrott.

Vad kan en avsiktslogg inte återställa?

Intent-loggen kan inte återskapa asynkrona skrivningar som aldrig lovades vara hållbara, ångra en avsiktlig överskrivning eller ersätta en oberoende säkerhetskopiakopia efter att varje onlineversion skadats.

Den kan inte heller korrigera dåligt RAM, firmwarebuggar i kontroller, oärliga diskflushar, misslyckade poolmedlemmar utöver redundans eller applikationskorruption som redan committats som ett giltigt nytt tillstånd.

En UPS, korrekt skrivordning, checksummor, snapshots, redundans och säkerhetskopior hanterar andra felgränser. ZIL bevarar specifikt erkänd synkron intent över ett avbrott.

Vanliga frågor

Är SLOG samma sak som ZIL?

Nej. ZIL är ZFS intent-loggmekanism. En SLOG är en valfri separat enhet som används för att lagra dessa intent-poster istället för att placera dem på huvudpoolen.

Påskyndar en SLOG varje NAS-skrivning?

Nej. Den påverkar främst synkrona skrivningar vars latens begränsas av hållbara logg-commits. Asynkrona skrivningar och läsbelastningar förbättras kanske inte.

Läses ZIL under normal drift?

Normalt används den inte som källa för filinläsningar. Den spelas upp efter ett avbrott när bekräftade synkrona operationer inte inkluderades i den senaste committade transaktionsgruppen.

Behöver ZFS en intent-logg för att förbli filsystemskonsistent?

ZFS copy-on-write transaktionsgrupper bevarar ett konsekvent committat träd. Intent-loggen lägger till återställning av erkända synkrona operationer som inträffade efter den committade punkten.

Slutsats

En ZFS intent-logg påskyndar inte alla typer av återställning. Dess exakta uppgift är att bevara och spela upp bekräftade synkrona operationer som ännu inte nått huvudtransaktionsgruppen. En låg-latens, strömavbrottsskyddad SLOG kan göra dessa commit snabbare, medan säkerhetskopior, redundans, checksummor, snapshots och en UPS fortsätter att skydda mot olika felgränser.