On Sat, Nov 30, 2019 at 02:20:42PM -0700, Chris Murphy wrote: > On Sat, Nov 30, 2019 at 12:46 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > On Wed, Nov 27, 2019 at 02:43:48PM -0700, Chris Murphy wrote: > > > On Wed, Nov 27, 2019 at 12:18 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > ...snip... > > > > > > > > I'd love to explore using Btrfs for doing it. I have no idea how to > > > > get started with that... > > > > > > Before Btrfs specific, I'd ask how much compression configurability is > > > needed in the compose system and where? That relates to plain squashfs > > > images as well as hypothetical Btrfs images. Is there any advantage to > > > having Rawhide use zstd:3 since these nightlies are throw away? These > > > would be much faster to create and use than xz or zstd:16, but the ISO > > > size would be a lot bigger, maybe 25% bigger. And then for branched > > > nightlies, RCs, and releases, use zstd:16 or even zstd:19? Could the > > > granularity be compress=low,medium,high? And that is then translated > > > by lmc or even the installer, into the specific level numbers? This is > > > in effect the question I'm posing here: > > > https://pagure.io/releng/issue/8581#comment-613760 > > > > I think we should just use the same everywhere, or we risk testing > > something that is not actually what we ship. > > I'm definitely advocating testing what will be shipped: > Test and ship zstd:3 for Rawhide > Test and ship zstd:16 for branched (nightlies, RC, release) > > I'd casually estimate zstd:3 is 2x faster to create the image than > zstd:16 - but since the compose system is typically throwing something > like 32 cores at these tasks, it may not substantially reduce the > overall compose time. Yeah, but then we aren't using Rawhide to test the thing that will go into the next branched. So, say there's some zstd bug or a size issue or something we don't catch in rawhide and then have to figure out months later in branched. I'd really prefer we just use the same for both. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
