-
Notifications
You must be signed in to change notification settings - Fork 35
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
Info drop internal xattrs #288
base: main
Are you sure you want to change the base?
Conversation
This exercises edge cases in the dumpfile. Signed-off-by: Colin Walters <[email protected]>
Tracing through these xattrs, I found it helpful to have comments with the expansion. Signed-off-by: Colin Walters <[email protected]>
The roundtrip test currently fails with `special.dump`; I think this patch is in the right direction but...I think what we were writing into the EROFS superblock for the userxattr is wrong...which means fixing this in the obvious way is a format break. Signed-off-by: Colin Walters <[email protected]>
I'm not sure we're actually wrong here. But these things are mind-bending, so maybe I'm mistaken. Here is the situation this is targeting: We have an "image" that contains a traditional whiteout node. We want to create an erofs+overlayfs from this, such that when it is mounted (by root), the resulting file in the mount: Now, lets focus on c. In the erofs image we create a regular file with the "user.overlay.whiteout" xattr set. Since the composefs overlayfs is rootful, this xattr is passed on as-is and works as a xwhiteout for a second userxattr mount. However, it needs the parent directory to be marked for overlayfs to handle it. So, we set "user.overlay.opaque" to "x" to mark this. This xattr also is not touched by the composefs overlay mount, so it is available as-is for the second level userxattr overlayfs mount. I think maybe you misunderstood the reason for these xattrs. They are not because we want to mount the erofs image with userxattrs (that will not work for many reasons), but rather that the rootful overlayfs mount of the erofs image should produce a mount where the whiteout file is useful both for regular and userxattr mounts. |
Question though, should we convert an xwhiteout to a regular whiteout when we dump? |
Right! That makes sense. |
The first commit got reimplemented a different way. I pushed the second commit to #384 This PR is going to need some nontrivial thought at some point, but isn't critical. |
@alexlarsson I took a pass at #282 (comment) (this is only 76.3% baked, I got a little lost a few times in the quoting/processing here) but I'm pretty sure now what we've been writing into the EROFS blob is wrong. If I'm right about that...I think there's two options:
user.
namespace given that we can't mount an EROFS unprivileged anyways and that's super unlikely to change in the future?