repo: Add a checkout option to not hardlink zero-sized files #1752
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
In rpm-ostree we've hit a few cases where hardlinking zero-sized files causes us problems. The most prominent is lock files in `/usr/etc`, such as `/usr/etc/selinux/semanage.LOCK`. If there are two zero-sized lock files to grab, but they're hardlinked, then locking will fail. Another case here is if one is using ostree inside a container and don't have access to FUSE (i.e. `rofiles-fuse`), then the ostree hardlinking can cause files that aren't ordinarily hardlinked to become so, and mutation of one mutates all. An example where this is concerning is Python `__init__.py` files. Now, these lock files should clearly not be in the tree to begin with, but - we're not gaining a huge amount by hardlinking these files either, so let's add an option to disable it.
rh-atomic-bot
pushed a commit
that referenced
this pull request
Oct 11, 2018
In rpm-ostree we've hit a few cases where hardlinking zero-sized files causes us problems. The most prominent is lock files in `/usr/etc`, such as `/usr/etc/selinux/semanage.LOCK`. If there are two zero-sized lock files to grab, but they're hardlinked, then locking will fail. Another case here is if one is using ostree inside a container and don't have access to FUSE (i.e. `rofiles-fuse`), then the ostree hardlinking can cause files that aren't ordinarily hardlinked to become so, and mutation of one mutates all. An example where this is concerning is Python `__init__.py` files. Now, these lock files should clearly not be in the tree to begin with, but - we're not gaining a huge amount by hardlinking these files either, so let's add an option to disable it. Closes: #1752 Approved by: jlebon
|
@rh-atomic-bot retry |
|
☀️ Test successful - status-atomicjenkins |
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
Oct 11, 2018
This is prep for running inside (unprivileged) Kube containers as they exist today: coreos#1329 Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN. I think there's some work on FUSE-in-containers but I'm not sure of the current status. What rofiles-fuse here is doing here is protecting is the hardlinked repo imports. But if `--cachedir` isn't specified, that repository gets thrown away anyways. So there's no real value to using FUSE here. Also since nothing is cached, disable the devino cache. We also make use of --force-copy-zerosized that just landed in libostree: ostreedev/ostree#1752 Down the line ideally we gain the capability to detect if either unprivileged overlayfs/FUSE are available. Then if `--cachedir` is specified we can make things work.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
Oct 11, 2018
This is prep for running inside (unprivileged) Kube containers as they exist today: coreos#1329 Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN. I think there's some work on FUSE-in-containers but I'm not sure of the current status. What rofiles-fuse here is doing here is protecting is the hardlinked repo imports. But if `--cachedir` isn't specified, that repository gets thrown away anyways. So there's no real value to using FUSE here. Also since nothing is cached, disable the devino cache. We also make use of --force-copy-zerosized that just landed in libostree: ostreedev/ostree#1752 Down the line ideally we gain the capability to detect if either unprivileged overlayfs/FUSE are available. Then if `--cachedir` is specified we can make things work.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
Oct 12, 2018
This is prep for running inside (unprivileged) Kube containers as they exist today: coreos#1329 Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN. I think there's some work on FUSE-in-containers but I'm not sure of the current status. What rofiles-fuse here is doing here is protecting is the hardlinked repo imports. But if `--cachedir` isn't specified, that repository gets thrown away anyways. So there's no real value to using FUSE here. Also since nothing is cached, disable the devino cache. We also make use of --force-copy-zerosized that just landed in libostree: ostreedev/ostree#1752 Down the line ideally we gain the capability to detect if either unprivileged overlayfs/FUSE are available. Then if `--cachedir` is specified we can make things work.
rh-atomic-bot
pushed a commit
to coreos/rpm-ostree
that referenced
this pull request
Oct 12, 2018
This is prep for running inside (unprivileged) Kube containers as they exist today: #1329 Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN. I think there's some work on FUSE-in-containers but I'm not sure of the current status. What rofiles-fuse here is doing here is protecting is the hardlinked repo imports. But if `--cachedir` isn't specified, that repository gets thrown away anyways. So there's no real value to using FUSE here. Also since nothing is cached, disable the devino cache. We also make use of --force-copy-zerosized that just landed in libostree: ostreedev/ostree#1752 Down the line ideally we gain the capability to detect if either unprivileged overlayfs/FUSE are available. Then if `--cachedir` is specified we can make things work. Closes: #1591 Approved by: jlebon
rh-atomic-bot
pushed a commit
to coreos/rpm-ostree
that referenced
this pull request
Oct 12, 2018
This is prep for running inside (unprivileged) Kube containers as they exist today: #1329 Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN. I think there's some work on FUSE-in-containers but I'm not sure of the current status. What rofiles-fuse here is doing here is protecting is the hardlinked repo imports. But if `--cachedir` isn't specified, that repository gets thrown away anyways. So there's no real value to using FUSE here. Also since nothing is cached, disable the devino cache. We also make use of --force-copy-zerosized that just landed in libostree: ostreedev/ostree#1752 Down the line ideally we gain the capability to detect if either unprivileged overlayfs/FUSE are available. Then if `--cachedir` is specified we can make things work. Closes: #1591 Approved by: jlebon
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In rpm-ostree we've hit a few cases where hardlinking zero-sized
files causes us problems. The most prominent is lock files in
/usr/etc, such as/usr/etc/selinux/semanage.LOCK. If thereare two zero-sized lock files to grab, but they're hardlinked,
then locking will fail.
Another case here is if one is using ostree inside a container
and don't have access to FUSE (i.e.
rofiles-fuse), then theostree hardlinking can cause files that aren't ordinarily hardlinked
to become so, and mutation of one mutates all. An example where
this is concerning is Python
__init__.pyfiles.Now, these lock files should clearly not be in the tree to begin
with, but - we're not gaining a huge amount by hardlinking these
files either, so let's add an option to disable it.