Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete btrfs volume if it exists when using the overlay driver #7461

Merged
merged 1 commit into from Aug 30, 2021

Conversation

taylorsilva
Copy link
Member

Changes proposed by this PR

closes #7430

We found that if you ended up in a state where you were trying to run a
worker with overlay and created the overlay mounts intside a btrfs
mount, lots of weird stuff would happen with volume creation and COW
volumes specifically.

This commit ensures that if you're using overlay and the volume path is
a btrfs mount, then the btrfs mount is cleaned up.

Release Note

  • Made worker initialization more stable if you're switching from btrfs to overlay. The worker will remove the btrfs mount if it exists before creating overlay mounts

Copy link
Contributor

@aoldershaw aoldershaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the chart we iterate over all of the subvolumes and delete them individually - is this necessary here too?

but only when using the overlay driver.

We found that if you ended up in a state where you were trying to run a
worker with overlay and created the overlay mounts intside a btrfs
mount, lots of weird stuff would happen with volume creation and COW
volumes specifically.

This commit ensures that if you're using overlay and the volume path is
a btrfs mount, then btrfs mount is cleaned up.

Signed-off-by: Taylor Silva <tsilva@pivotal.io>
Co-authored-by: Esteban Foronda <eforonda@vmware.com>
@taylorsilva
Copy link
Member Author

I don't think we need to delete each sub-volume. The sub-volumes exist in the volume.img file which then gets rm'd after the btrfs volume is unmounted. The sub-volumes don't appear as mounts to the kernel, only the top-level btrfs volume appears as a mount to the kernel.

The issue we ran into during our testing was when there were overlay mounts inside the btrfs mount. Then the top-level btrfs volume could not be unmounted. The same does not happen when there are btrfs subvolumes.

@taylorsilva taylorsilva merged commit d51308d into master Aug 30, 2021
@taylorsilva taylorsilva deleted the issue/7430 branch August 30, 2021 17:35
@clarafu clarafu changed the title worker: delete btrfs volume if it exists when using the overlay driver Delete btrfs volume if it exists when using the overlay driver Sep 7, 2021
@clarafu clarafu added the release/undocumented This didn't warrant being documented or put in release notes. label Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug release/undocumented This didn't warrant being documented or put in release notes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Worker does not recover if btrfs volume is still mounted
3 participants