This repository has been archived by the owner on Nov 7, 2024. It is now read-only.
tar/import: Handle hardlinked changes into /sysroot #408
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
xref ostreedev#405 This test case reproduces the failure when we're trying to import a tar archive with hardlinks into `/sysroot`.
Some container build processes run without overlayfs inode indexing on - in this common scenario, overlayfs is not quite POSIX compliant because it will break the hardlink instead of modifying all versions. We need to handle this case of having *all* names for a hardlinked file being modified though too. If the serialized tar stream has the file in `/sysroot` be the canonical version, then because we drop out that file here, we'll fail to import. Fix this by significantly beefing up the tar filtering/reprocessing logic: - When we see a *modified* file in `/sysroot` with a nonzero timestamp, cache its data into a lookaside temporary directory - If we then see a hardlink to that file path, make *that* file be the canonical version in e.g. `/usr`. - Any further hardlinks to `/sysroot` instead become hardlinks to the new canonical one. (Arguably perhaps...we should actually not have used hardlinks in ostree containers at all, but injected this metadata in some other way. But, the ship has sailed on that) Closes: ostreedev#405
|
We could probably just merge this directly and close #406 - but I wanted to demonstrate in 406 that the new test case was "successfully failing". |
cgwalters
added a commit
to cgwalters/ai-lab-recipes
that referenced
this pull request
Jun 30, 2024
This (not tested locally) change should work around containers/bootc#637 It's all tricky because you'll only again see this when using the `vfs` backend. The `overlay` backend always breaks hardlinks. For more, see e.g. ostreedev/ostree-rs-ext#408 Signed-off-by: Colin Walters <[email protected]>
tsorya
pushed a commit
to tsorya/ai-lab-recipes
that referenced
this pull request
Jul 9, 2024
This (not tested locally) change should work around containers/bootc#637 It's all tricky because you'll only again see this when using the `vfs` backend. The `overlay` backend always breaks hardlinks. For more, see e.g. ostreedev/ostree-rs-ext#408 Signed-off-by: Colin Walters <[email protected]>
tsorya
pushed a commit
to tsorya/ai-lab-recipes
that referenced
this pull request
Jul 9, 2024
This (not tested locally) change should work around containers/bootc#637 It's all tricky because you'll only again see this when using the `vfs` backend. The `overlay` backend always breaks hardlinks. For more, see e.g. ostreedev/ostree-rs-ext#408 Signed-off-by: Colin Walters <[email protected]>
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.
Builds on #406
tar/import: Handle hardlinked changes into /sysroot
Some container build processes run without overlayfs inode indexing
on - in this common scenario, overlayfs is not quite POSIX compliant
because it will break the hardlink instead of modifying all versions.
We need to handle this case of having all names for a hardlinked
file being modified though too. If the serialized tar stream
has the file in
/sysrootbe the canonical version, then becausewe drop out that file here, we'll fail to import.
Fix this by significantly beefing up the tar filtering/reprocessing
logic:
/sysrootwith a nonzero timestamp,cache its data into a lookaside temporary directory
be the canonical version in e.g.
/usr./sysrootinstead become hardlinksto the new canonical one.
(Arguably perhaps...we should actually not have used hardlinks
in ostree containers at all, but injected this metadata in
some other way. But, the ship has sailed on that)
Closes: #405