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

WIP/DNM / Support overlayfs whiteout character files #2713

Closed
wants to merge 2 commits into from

Conversation

mangelajo
Copy link
Contributor

@mangelajo mangelajo commented Sep 13, 2022

This is yet incomplete and untested, it doesn't work yet.

Related-Issue: #2712

@openshift-ci
Copy link

openshift-ci bot commented Sep 13, 2022

Hi @mangelajo. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@lucab
Copy link
Member

lucab commented Sep 14, 2022

/hold

I'd like to push back on this, I don't think it is a good idea. The thread at #2712 is still ongoing, let's find better alternatives there.

@mangelajo
Copy link
Contributor Author

mangelajo commented Sep 14, 2022

/hold

I'd like to push back on this, I don't think it is a good idea. The thread at #2712 is still ongoing, let's find better alternatives there.

please participate on the thread and provide alternatives, and please elaborate why you think it's not a good idea.

@lucab
Copy link
Member

lucab commented Sep 14, 2022

I'll let @cgwalters drive the conversation there to avoid too many voices, but I pretty much share the hints in #2712 (comment).

@mangelajo mangelajo force-pushed the support-char-whiteouts branch from 49077e9 to ecd0a0f Compare September 16, 2022 10:43
@@ -2014,7 +2014,7 @@ file_header_parse (GVariant *metadata,
mode = GUINT32_FROM_BE (mode);
g_autoptr(GFileInfo) ret_file_info = _ostree_mode_uidgid_to_gfileinfo (mode, uid, gid);

if (S_ISREG (mode))
if (S_ISREG (mode) || S_ISCHR(mode))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have a common helper that checks specifically for whiteouts, which needs to take either a GFileInfo or a struct stat.

We still do want to error out for any character devices that are not whiteouts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes in this case we are reconstructing the info from the ostree data and we have a check in L2009 that verifies rdev==0, so that´s assumed down here.

We could put the rdev info back into the GFileInfo and then have a validator to make it more explicit.

@@ -4474,7 +4475,7 @@ ostree_repo_load_file (OstreeRepo *self,
if (S_ISLNK (stbuf.st_mode))
g_file_info_set_symlink_target (*out_file_info, symlink_target);
else
g_assert (S_ISREG (stbuf.st_mode));
g_assert (S_ISREG (stbuf.st_mode) || (S_ISCHR(stbuf.st_mode) && stbuf.st_rdev == 0));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the check we want to generalize everywhere I think, as e.g. _ostree_is_whiteout (&stbuf).

@cgwalters
Copy link
Member

/ok-to-test

@cgwalters
Copy link
Member

I do want to note here the last bit of #2712 (comment)

There's a bunch of code that will need touching for this, not just in ostree core but also in e.g. https://github.com/ostreedev/ostree-rs-ext/tree/main/lib/src/tar

which is that we could land this in ostree and that would probably work for your use case, but all that code that lives in ostree-rs-ext, such as e.g. ostree container encapsulate would fail.

And that gets into the whole topic of being able to "nest" container storage layers in container layers, which I think we do want longer term, which leads to #2712 (comment) or so.

@@ -2014,7 +2014,7 @@ file_header_parse (GVariant *metadata,
mode = GUINT32_FROM_BE (mode);
g_autoptr(GFileInfo) ret_file_info = _ostree_mode_uidgid_to_gfileinfo (mode, uid, gid);

if (S_ISREG (mode))
if (S_ISREG (mode) || S_ISCHR(mode))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes in this case we are reconstructing the info from the ostree data and we have a check in L2009 that verifies rdev==0, so that´s assumed down here.

We could put the rdev info back into the GFileInfo and then have a validator to make it more explicit.

@@ -2368,7 +2385,7 @@ _ostree_validate_bareuseronly_mode (guint32 content_mode,
return glnx_throw (error, "Content object %s: invalid mode 0%04o with bits 0%04o",
checksum, content_mode, invalid_modebits);
}
else if (S_ISLNK (content_mode))
else if (S_ISLNK (content_mode) || S_ISCHR(content_mode))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't use the helper functions here since at this point it's only mode

@@ -2400,7 +2417,7 @@ gboolean
ostree_validate_structureof_file_mode (guint32 mode,
GError **error)
{
if (!(S_ISREG (mode) || S_ISLNK (mode)))
if (!(S_ISREG (mode) || S_ISLNK (mode) || S_ISCHR(mode)))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here.

@@ -301,7 +332,7 @@ commit_loose_regfile_object (OstreeRepo *self,
return FALSE;
}
else
g_assert (S_ISLNK (mode));
g_assert (S_ISLNK (mode) || S_ISCHR(mode));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here.

@mangelajo mangelajo force-pushed the support-char-whiteouts branch from 25f2623 to 11a4e2b Compare September 19, 2022 12:37
@mangelajo mangelajo force-pushed the support-char-whiteouts branch from 11a4e2b to c2ff1cc Compare September 19, 2022 12:38
@mangelajo
Copy link
Contributor Author

I'm working on another PR that follows the other suggested approach.

/* Otherwise, fall through and do the link, we should
* get EEXIST.
*/
/* Otherwise, fall through and do the link, we should
Copy link
Contributor Author

@mangelajo mangelajo Sep 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change shouldn't be here

@mangelajo
Copy link
Contributor Author

Dropping this approach in favor of #2717

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.

3 participants