-
Notifications
You must be signed in to change notification settings - Fork 236
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
decouple composefs and zstd:chunked #2016
Comments
@giuseppe PTAL |
@alexlarsson PTAL |
we have We could generate a composefs blob directly from the extracted tarball content, but we'd lose the other advantages we have with I think we still need to create a TOC (even in a simpler format without offsets to the payloads in the tarball stream) but we can avoid the temporary conversion to zstd |
So… the deduplication / lookup code can, in principle, be called from |
[… and I have a self-imposed moratorium on reviewing any changes that add options or complexity to |
Yeah...I didn't look more than superficially at this but I am sure you're right.
I guess as far as options, #2017 is actually higher priority from my PoV and obviously way simpler (and I'm curious if you agree with that option). But just to back up on this and help level set: right now I maintain a whole separate stack in bootc (ostree-rs-ext) that is today mapping non-zstd:chunked images ultimately into composefs (indirectly via ostree). My interest is in reducing this duplication, and that's partly where this issue came from. People are today booting via bootc into composefs from OS containers that are gzip, and I don't want to break that. |
Today,
Actually also requires:
And it's especially the
convert_images = true
that adds huge latency to pulls of images that aren't already in zstd:chunked format.I am probably willing to put some time in code behind decoupling these two things, as I do not believe at a technical level they need to be coupled.
If someone feels really strongly, it's OK to close this issue though.
In the meantime at a practical level, this issue will just be a reference point for what is likely to be a FAQ of "why does enabling composefs slow down my image pulls"?
The text was updated successfully, but these errors were encountered: