Så förhindrar du att Btrfs-metadata tar slut vid snapshot-intensiva arbetsbelastningar på hemmaservrar
Btrfs-servrar med många ögonblicksbilder undviker slut på metadata genom att skydda marginalen för oallokerade blockgrupper och begränsa metadataförändringar innan ENOSPC uppstår.
Den här förebyggande artikeln förutsätter att filsystemet fortfarande är friskt och skrivbart. Målet är att övervaka metadataallokering, oallokerat utrymme på enheten, antalet ögonblicksbilder och förändringar i filsystemets objekt tillräckligt tidigt för att servern aldrig ska nå det återställningsläge som behandlas i en reparationsguide för ENOSPC. Det är inte enbart frekvensen av ögonblicksbilder som är problemet; lagringstiden, uppdateringsmönster, atime-skrivningar, miljontals filsystemobjekt och underhåll som körs vid olämpliga tidpunkter avgör tillsammans hur snabbt metadatabelastningen ökar.
Spåra metadata och oallokerat utrymme tillsammans
Notera resultatet från btrfs filesystem usage under en normal dag och efter den mest belastande perioden för ögonblicksbilder eller säkerhetskopiering. Följ allokerad metadata, använd metadata, dataallokering och oallokerat utrymme på enheten i stället för att enbart förlita dig på df.
En genomgång av Btrfs-lagring förklarar att oallokerat utrymme finansierar nya blockgrupper när filsystemet behöver ytterligare metadatakapacitet.
Skapa en avisering kring en försiktig marginalnivå som passar din arbetsbelastning i stället för en universell procentsats. Den användbara signalen är inte bara att ”metadata används till 70 procent”, utan om Btrfs fortfarande har tillräckligt med oallokerat utrymme för att skapa nästa nödvändiga metadata-blockgrupp.
Avisera innan ENOSPC blir självförstärkande
Slut på metadata kan göra rensning svårare eftersom även borttagning av ögonblicksbilder och filer kräver metadatauppdateringar. Betrakta minskande oallokerat utrymme som en tidig varning och agera medan vanliga underhållskommandon fortfarande har utrymme att fungera.
En fokuserad ENOSPC-referens förklarar att ENOSPC börjar med brist på marginalutrymme och inte först när varje synlig byte på filsystemet är förbrukad.
När marginalnivån underskrids ska du först pausa skapandet av nya ögonblicksbilder och metadataintensiva jobb. Starta inte en omfattande ombalansering enbart för att aviseringen utlöstes; bekräfta vilken utrymmesklass som är hårt belastad och behåll tillräckligt med arbetsutrymme för den minsta korrigerande åtgärden.
Begränsa lagringstiden för ögonblicksbilder i stället för enbart frekvensen
Ögonblicksbilder varje timme kan vara praktiska när gamla ögonblicksbilder rensas bort förutsägbart och förändringstakten är måttlig. Det farliga mönstret är en ständigt växande tidslinje som bevarar många generationer av filer som ändras ofta.
En praktisk Snapper-konfiguration visar hur lagringsgränser begränsar historiken i stället för att automatiseringen samlar på sig ett obegränsat antal återställningspunkter.
Välj lagringstid utifrån återställningsvärde: fler kortsiktiga punkter för aktiv konfiguration, färre långsiktiga punkter för virtuella maskinavbildningar och containerdata med hög förändringstakt samt separata säkerhetskopior för sådant vars återställningshorisont sträcker sig längre än den lokala kapaciteten för ögonblicksbilder.
Minska metadataförändringar under perioder med ögonblicksbilder
Leta efter arbetsbelastningar som skriver om metadata utan att ändra användbart filinnehåll: frekventa uppdateringar av åtkomsttider, paket- eller containerträd med mycket stora mängder objekt, roterande cachefiler och program som berör många kataloger vid varje genomsökning.
LWN:s analys av Btrfs-ögonblicksbilder noterar att atime-uppdateringar förstärker förändringstakten även om vanliga ögonblicksbilder till en början delar befintliga data och metadata.
Använd monterings- och programinställningar som passar arbetsbelastningen, till exempel genom att undvika onödiga ändringar av åtkomsttider när det är säkert. Inaktivera inte metadatafunktioner globalt utan att förstå programmens krav; minska först sådana skrivningar som inte har något återställningsvärde.
Övervaka metadatans tillväxt som en trend
Samla in statistik över metadataanvändning och Btrfs-fel på samma instrumentpanel som poolens kapacitet. Jämför tillväxt från dag till dag och vecka till vecka med antalet ögonblicksbilder, containerdistributioner, säkerhetskopieringsjobb och större förändringar i filträd.
Netdatas aktuella Btrfs-insamlare visar att metadataanvändning kan övervakas i stället för att metadatabelastningen bara blir synlig under en interaktiv felsökningssession.
Avisera både vid en utveckling över tid och vid en absolut tröskel. En server som ökar sin metadata med flera gigabyte per dag efter en ny säkerhetskopieringspolicy behöver undersökas långt innan den återstående marginalen når en kritisk nivå.
Testa arbetsbelastningar med många ögonblicksbilder innan lagringstiden utökas
När du ökar frekvensen av ögonblicksbilder eller lägger till en ny container, ett nytt säkerhetskopieringsverktyg eller en arbetsbelastning med många små filer ska du mäta metadatans tillväxt under en representativ cykel innan policyn utökas till hela servern.
En aktuell artikel om Btrfs interna funktioner förklarar att metadata följer filsystemets struktur i stället för att metadata är en fast overhead som enbart bestäms av det totala antalet filbyte.
Den förebyggande policyn fungerar när metadatans tillväxt är förutsägbar, lagringstiden rensas enligt schemat och den oallokerade marginalen återhämtar sig efter normalt underhåll. Den relaterade ZimaSpace-artikeln om återställning efter Btrfs metadata-ENOSPC är rätt nästa steg när skrivningar börjar misslyckas eller filsystemet redan har tömt sitt arbetsutrymme för allokering.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
