This repository has been archived by the owner on Feb 17, 2024. It is now read-only.
ocifs: read-write layers #231
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Achille Roussel <[email protected]>
chriso
approved these changes
Aug 28, 2023
Signed-off-by: Achille Roussel <[email protected]>
Pryz
approved these changes
Aug 28, 2023
achille-roussel
force-pushed
the
ocifs-read-write
branch
from
6cddfd6
to
8ff36ab
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following up on #229, this PR makes the OCI layered file system writable if the underlying layers can be written. This allows the application to mutate the content of file systems mounted at specific locations with
sandbox.SubFS.While technically, this enables the use cases we're trying to implement (read-only file system + writable mount points), I'm feeling increasingly uneasy about this being somewhat of a workaround for the lack of a more general-purpose copy-on-write mechanism; I'm hoping we'll find the time to get back to working on this at some point: this model only works if the mount points are made opaque (e.g. masking files from layers below) because otherwise the application may end up in very strange situations where it can create directory entries in the writable layer but cannot mutate some of the entries seen from the layers below etc... as long as we apply strong controls over how the file systems are constructed we shouldn't run into too many issues, but it still feels like living on borrowed time.