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

[24.0 backport] volume/local: Don't unmount, restore mounted status #46366

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Aug 29, 2023


On startup all local volumes were unmounted as a cleanup mechanism for the non-clean exit of the last engine process.

This caused live-restored volumes that used special volume opt mount flags to be broken. While the refcount was restored, the _data directory was just unmounted, so all new containers mounting this volume would just have the access to the empty _data directory instead of the real volume.

With this patch, the mountpoint isn't unmounted. Instead, if the volume is already mounted, just mark it as mounted, so the next time Mount is called only the ref count is incremented, but no second attempt to mount it is performed.

- What I did
Fixed the case where live-restore of volumes that specified custom volume opts wouldn't work properly.

- How I did it
See commits.

- How to verify it
CI

- Description for the changelog

- Fixed a bug which caused named volumes that set custom `device` or `type` volume option to be unmounted when restarting the daemon and not live-restoring it properly.

- A picture of a cute animal (not mandatory but encouraged)

Make sure that the content in the live-restored volume mounted in a new
container is the same as the content in the old container.
This checks if volume's _data directory doesn't get unmounted on
startup.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit aef703f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On startup all local volumes were unmounted as a cleanup mechanism for
the non-clean exit of the last engine process.

This caused live-restored volumes that used special volume opt mount
flags to be broken. While the refcount was restored, the _data directory
was just unmounted, so all new containers mounting this volume would
just have the access to the empty _data directory instead of the real
volume.

With this patch, the mountpoint isn't unmounted. Instead, if the volume
is already mounted, just mark it as mounted, so the next time Mount is
called only the ref count is incremented, but no second attempt to mount
it is performed.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 2689484)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah merged commit 1a79695 into moby:24.0 Aug 29, 2023
102 checks passed
@thaJeztah thaJeztah deleted the 24.0_backport_volume-local-restore-mounted-status branch August 29, 2023 19:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants