-
Notifications
You must be signed in to change notification settings - Fork 93
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
Support reading zstd-compressed initrds #920
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
// the magic number of another frame, and decide whether we're done. The | ||
// raw decoder always stops at frame boundaries, so this is reliable. If | ||
// done, return Ok(0) and allow the caller to decide what it wants to do | ||
// about trailing data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered opening a PR upstream to support this in the higher-level API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. In zstd there are two parts to EOF detection: noticing we're at the end of a frame and checking whether another frame is coming. Upstream could do the first part, but I don't think the second part can be done robustly without something like PeekReader
, which the upstream API can't require. And it seems awkward to provide a high-level API that requires the caller to manually read ahead and check magic numbers. Allowing trailing data is a pretty obscure requirement, really, so sticking to the low-level API seems fine.
This adds a library dependency on libzstd, since we're not having the zstd crate statically link it.
Minor updates for comments and to avoid hardcoding the magic numbers. |
On my system, relative to gzip -9, it roughly halves decompression time at boot while also reducing initrd size. RHCOS 8 can't inherit this because the RHEL 8 kernel doesn't enable CONFIG_RD_ZSTD. This requires coreos-installer to support decoding zstd (for `coreos-installer pxe customize`), which is coreos/coreos-installer#920. For coreos/fedora-coreos-tracker#1247.
On my system, relative to gzip -9, it roughly halves decompression time at boot while also reducing initrd size. RHCOS 8 can't inherit this because the RHEL 8 kernel doesn't enable CONFIG_RD_ZSTD. This requires coreos-installer to support decoding zstd (for `coreos-installer pxe customize`), which is coreos/coreos-installer#920. For coreos/fedora-coreos-tracker#1247.
On my system, relative to gzip -9, it roughly halves decompression time at boot while also reducing initrd size. RHCOS 8 can't inherit this because the RHEL 8 kernel doesn't enable CONFIG_RD_ZSTD. This requires coreos-installer to support decoding zstd (for `coreos-installer pxe customize`), which is coreos/coreos-installer#920. For coreos/fedora-coreos-tracker#1247.
No description provided.