Varför förblir en Btrfs-ögonblicksbild upptagen efter att varje appcontainer har stoppats?

En stoppad container kan göra en Btrfs-snapshot upptagen när en annan process, monteringsnamnrymd, bind-montering, sändningsjobb eller kapslad under­volym fortfarande refererar till den.

När en applikationscontainer stoppas avslutas huvudprocessen, men det bevisar inte att alla relaterade monteringar, hjälpprocesser, runtime-shims, skal-sessioner, säkerhetskopieringsjobb eller namnrymder har släppt snapshot-sökvägen. Btrfs kan också neka borttagning när målet är monterat, används i en sändning, är konfigurerat som standardundervolym eller innehåller kapslade under­volymer. Fastställ den exakta referensen innan du tvingar fram en avmontering eller tar bort containerdata.

Bekräfta det exakta Btrfs-objektet och felet

Notera den fullständiga sökvägen till snapshoten, under­volymens ID, överordnade ID, skrivskyddsstatus, UUID, mottagna UUID och det exakta borttagningsfelet. Bekräfta att sökvägen är en Btrfs-undervolym och inte en vanlig katalog inuti en sådan.

Referensen för Btrfs-under­volymer förklarar att snapshots är under­volymer och beskriver villkor som förhindrar borttagning, bland annat status som standardundervolym och en aktiv sändning.

Om felet inte är EBUSY följer du det faktiska felet. Problem med behörighet, skrivskyddad montering, standardundervolym och kapslade under­volymer kräver andra kontroller än en aktiv monteringsreferens.

Skilj på att stoppa och ta bort en container

Lista containers i körande, stoppade, avslutade och borttagande tillstånd. Notera container-ID:n som använde snapshoten via bind-monteringar, namngivna volymer eller en Btrfs-lagringsdrivrutin.

Dockers CLI-referens visar att docker stop skickar en signal till huvudprocessen; det innebär inte att containerdefinitionen, runtime-metadata eller alla lagringsrelationer på värden har tagits bort.

Ta inte bort snapshoten enbart för att applikationens användargränssnitt visar att stacken är stoppad. Kontrollera om en omstartspolicy, hälsohjälp, exec-skal, sidovagn eller container-runtimeprocess fortfarande finns kvar.

Inspektera monteringar i alla relevanta namnrymder

Jämför värdens monteringstabell med monteringsnamnrymderna för containerruntime, hjälpprocesser för stoppade containers, säkerhetskopieringsagenter och långlivade skal som har gått in i containern.

Linux-manualen förklarar att monteringsnamnrymder isolerar monteringslistor, så en sökväg kan verka vara omonterad på värden samtidigt som den fortfarande är monterad i en annan processnamnrymd.

Använd processpecifik monteringsinformation i stället för att bara kontrollera det aktuella skalet. En lat avmontering från värden kan dölja symtomet utan att frigöra namnrymden som fortfarande äger referensen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Leta efter containermonteringar som finns kvar i en annan namnrymd

Identifiera process-ID:t för containerruntime, shim, övervakningsagent eller hjälpprocess som kan behålla namnrymden. Inspektera dess monteringsträd och källsökvägen som motsvarar Btrfs-snapshoten.

Red Hat beskriver ett verifierat fall där en montering i en annan namnrymd orsakar rensningsfel av typen enhet eller resurs upptagen, vilket motsvarar situationen där värden verkar vara fri men snapshoten fortfarande är refererad.

Avsluta endast den bevisligen inaktuella hjälpprocessen eller starta om den relevanta runtime-miljön under ett planerat underhållsfönster. Att avsluta orelaterade namnrymdsägare kan störa andra containers och monteringar.

Använd fuser och kontroller av öppna handtag med hänsyn till namnrymdsbegränsningar

Kontrollera öppna filer, aktuella arbetskataloger, mappade filer och användare av monteringen under snapshot-sökvägen. Kör verktygen med tillräckliga behörigheter och jämför deras processlista med runtimeprocesserna.

Debians fuser-manual varnar för att verktyget kanske inte ser blockenheter som monterats av processer i en annan monteringsnamnrymd, så ett tomt resultat bevisar inte att snapshoten är oanvänd.

Kontrollera även skalsessioner vars aktuella katalog finns inuti snapshoten, filindexeringstjänster, antivirusgenomsökare, säkerhetskopieringsläsare och program som följer loggar. Stäng en bekräftad användare i taget och försök igen med den skrivskyddade statuskontrollen.

Uteslut monterade, standardiserade, kapslade och sändande under­volymer

Lista alla monteringar som pekar på snapshotens under­volym-ID, kontrollera filsystemets standardundervolym, räkna upp kapslade under­volymer och inspektera aktiva Btrfs-sändningsjobb.

ArchWiki rekommenderar att en monterad under­volym inte ska tas bort, vilket gör kontroll av monteringsidentitet och kapslad layout nödvändig före borttagning.

Att stoppa applikationscontainers stoppar inte en oberoende Btrfs-sändning, snapshotreplikering eller säkerhetskopieringsprocess. Vänta tills sändningen är klar eller stoppa den på ett ordnat sätt och kontrollera sedan snapshotens status igen.

Frigör den bekräftade referensen och ta bort säkert

Avmontera snapshoten från den namnrymd som äger den, ta bort eller starta om det inaktuella container-runtimeobjektet när det är lämpligt, lämna arbetskataloger, stoppa den bekräftade sändningsuppgiften och ta bort kapslade under­volymer i beroendeordning.

ZimaSpaces artikel om snapshotar av NAS-appdata ger närliggande kontext för att identifiera vilka beständiga sökvägar och applikationstillstånd en containersnapshot faktiskt omfattar.

Problemet är löst när ingen namnrymd eller process refererar till under­volymen, den korrekta snapshoten som inte är standard kan tas bort med det stödda Btrfs-kommandot, bakgrundsrensningen är klar och applikationsstacken startar om med sina avsedda aktiva datasökvägar intakta.