Waarom blijft een Btrfs-snapshot actief nadat elke appcontainer is gestopt?

Een gestopte container kan een Btrfs-snapshot in gebruik houden wanneer een ander proces, een mountnamespace, bindmount, send-taak of genest subvolume er nog naar verwijst.

Het stoppen van een applicatiecontainer beëindigt het hoofdproces, maar bewijst niet dat elke gerelateerde mount, elk hulpproces, elke runtime-shim, shellsessie, back-uptaak of namespace het snapshotpad heeft vrijgegeven. Btrfs kan het verwijderen ook weigeren wanneer het doel is gemount, betrokken is bij een send-bewerking, als standaardsubvolume is ingesteld of geneste subvolumes bevat. Stel eerst de exacte verwijzing vast voordat u een unmount forceert of containergegevens verwijdert.

Bevestig het exacte Btrfs-object en de fout

Noteer het volledige snapshotpad, de subvolume-ID, de bovenliggende ID, de alleen-lezenstatus, de UUID, de ontvangen UUID en de exacte verwijderingsfout. Bevestig dat het pad een Btrfs-subvolume is en geen gewone map binnen een subvolume.

De referentie voor Btrfs-subvolumes legt uit dat snapshots subvolumes zijn en documenteert omstandigheden die verwijdering verhinderen, waaronder de status als standaardsubvolume en een actieve send-bewerking.

Als de fout niet EBUSY is, volg dan de daadwerkelijke oorzaak. Problemen met machtigingen, een alleen-lezenmount, een standaardsubvolume en geneste subvolumes vereisen andere controles dan een actieve mountverwijzing.

Maak onderscheid tussen een container stoppen en verwijderen

Toon containers met de statussen actief, gestopt, beëindigd en wordt verwijderd. Noteer de container-ID's die het snapshot gebruikten via bindmounts, benoemde volumes of een Btrfs-opslagstuurprogramma.

De CLI-referentie van Docker laat zien dat docker stop een signaal naar het hoofdproces stuurt; dit betekent niet dat de containerdefinitie, runtime-metadata of elke opslagrelatie aan de hostzijde is verwijderd.

Verwijder het snapshot niet alleen omdat de applicatie-interface aangeeft dat de stack is gestopt. Controleer of er nog een herstartbeleid, health-helper, exec-shell, sidecar of container-runtimeproces bestaat.

Inspecteer mounts in elke relevante namespace

Vergelijk de mounttabel van de host met de mountnamespaces van de containerruntime, helpers voor gestopte containers, back-upagenten en langdurige shells die de container zijn binnengegaan.

De Linux-handleiding legt uit dat mountnamespaces mountlijsten isoleren, waardoor een pad op de host ongemount kan lijken terwijl het in de namespace van een ander proces nog steeds gemount is.

Gebruik procesgebonden mountinformatie in plaats van alleen de huidige shell te controleren. Een luie unmount vanaf de host kan het symptoom verbergen zonder de namespace vrij te geven die de verwijzing nog bezit.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zoek naar containermounts die in een andere namespace zijn achtergebleven

Identificeer de proces-ID van de containerruntime, shim, monitoringagent of helper die de namespace mogelijk vasthoudt. Inspecteer de mountstructuur ervan en het bronpad dat overeenkomt met het Btrfs-snapshot.

Red Hat documenteert een geverifieerde situatie waarin een mount in een andere namespace fouten veroorzaakt waarbij het apparaat of de bron in gebruik is. Dit komt overeen met de situatie waarin de host leeg lijkt, maar er nog steeds naar het snapshot wordt verwezen.

Beëindig alleen de aantoonbaar verouderde helper of start de relevante runtime opnieuw tijdens een onderhoudsvenster. Het beëindigen van niet-gerelateerde namespace-eigenaars kan andere containers en mounts verstoren.

Gebruik fuser en controles op open handles, met oog voor namespacebeperkingen

Controleer geopende bestanden, huidige werkmappen, toegewezen bestanden en gebruikers van de mount onder het snapshotpad. Voer de hulpprogramma's uit met voldoende rechten en vergelijk hun proceslijst met de runtimeprocessen.

De fuser-handleiding van Debian waarschuwt dat het mogelijk geen blokapparaten ziet die door processen in een andere mountnamespace zijn gemount. Een leeg resultaat bewijst dus niet dat het snapshot ongebruikt is.

Controleer ook shellsessies waarvan de huidige map zich in het snapshot bevindt, bestandsindexeringsdiensten, antivirusscanners, back-uplezers en processen die applicatielogs volgen. Sluit één bevestigde gebruiker tegelijk af en probeer de alleen-lezenstatuscontrole opnieuw.

Sluit gemounte, standaard-, geneste en verzendende subvolumes uit

Toon elke mount die naar de subvolume-ID van het snapshot verwijst, controleer het standaardsubvolume van het bestandssysteem, inventariseer geneste subvolumes en inspecteer actieve Btrfs-send-taken.

ArchWiki adviseert dat een gemount subvolume niet moet worden verwijderd. Daarom zijn de mountidentiteit en de geneste structuur verplichte controles vóór verwijdering.

Het stoppen van applicatiecontainers stopt geen onafhankelijke Btrfs-send, snapshotreplicatie of back-upproces. Wacht tot de send-bewerking is voltooid of stop deze netjes en controleer daarna de snapshotstatus opnieuw.

Maak de vastgestelde verwijzing vrij en verwijder veilig

Unmount het snapshot vanuit de namespace die het bezit, verwijder of start het verouderde container-runtimeobject opnieuw wanneer dat passend is, verlaat werkmappen, stop de bevestigde send-taak en verwijder geneste subvolumes in afhankelijkheidsvolgorde.

Het ZimaSpace-artikel over het maken van snapshots van NAS-appgegevens biedt aanvullende context voor het vaststellen welke permanente paden en applicatiestatussen een containersnapshot daadwerkelijk omvat.

Het probleem is opgelost wanneer geen enkele namespace of geen enkel proces meer naar het subvolume verwijst, het juiste niet-standaardsnapshot via de ondersteunde Btrfs-opdracht wordt verwijderd, de achtergrondopruiming is voltooid en de applicatiestack opnieuw start met de beoogde actieve datapaden intact.