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. > I also don't think we should tie this work to btrfs. > If it also works there, great, but requiring that would be moving us to > btrfs by default, which we have not done. The btrfs stuff is hypothetical, to take into account the potential for future image types, so that it's not made more difficult to add them in the future. There aren't enough ducks in a row to actually put a switch into koji for something that doesn't exist in lorax/lmc or anaconda or dracut. The file system for the Live rootfs payload is totally orthogonal to the default filesystem used for the installation target. Live installs always use rsync. A long time ago the nested ext4 rootfs was dd copied to the target, and then resized to fit the partition/LV. But that hasn't been true since ancient times. -- Chris Murphy _______________________________________________ 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
