Thanks for the early feedback! On Mon, Jun 1, 2020 at 7:58 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > * Reading through the Change, you write: > "using a ZRAM to RAM ratio of 1:2, and capped† to 4GiB" and then you > talk about examples which are using 50% of RAM as ZRAM. Which is it? A > ratio of 1:2 implies using 33% of RAM as ZRAM. This ratio is just a fraction, part of whole, where RAM is the whole. This convention is used in the zram (package). Note that /dev/zram0 is a virtual block device, similar to the 'lvcreate -V' option for thin volumes, size is a fantasy. And the ZRAM device size is not a preallocation of memory. If the compression ratio 2:1 (i.e. 200%) holds, then a ZRAM device sized to 50% of RAM will not use more than 25% of RAM. I'll try to clear this up somehow; probably avoid using the term ratio and just go with fraction/percentage. And also note the use of 'zramctl' to see the actual compression ratio. > * This Change implies the de facto death of hibernation in Fedora. > Good riddance, IMHO. It never worked safely. UEFI Secure Boot put us on this path. There's still no acceptable authenticated encrypted hibernation image scheme, and the SUSE developer working on it told me a few months ago that the status is the same as last year and there's no ETA for when he gets the time to revisit it. > * Can the upgrade process be made to detect the lack of existing swap > and not enable the zswap in that case? (We're not using zswap at all in this implementation. zram!=zswap - easy mistake.) I expect in the "already has a swap partition" case, no one will complain about getting a 2nd swap device that's on /dev/zram0, because it'll just be faster and "spill over" to the bigger swap-on-disk. It's the use case where "I explicitly did not create a swap device because I hate swap thrashing" that I suspect there may be complaints. We can't detect that sentiment. All we could do is just decide that no upgrades get the feature. > Generally, we should probably assume (given existing defaults) that > anyone who has no swap running chose that explicitly and to change it > would lead to complaints. Perhaps. But I assert their decision is based on both bad information (wrong assumptions), and prior bad experience. Even if in the end the decision is to not apply the feature on upgrades, I think it's worth some arguing to counter wrong assumptions and bad experiences. > * If you're going to do the Supplements:, you need to do `Supplements: > fedora-release-common` or you won't get everyone. The `fedora-release` > package is for non-Edition/Spin installs. Right. Fixed. I suggest these three lines in the configuration (I've updated the change proposal how to test section to include this): [zram0] memory-limit = none zram-fraction = 0.5 There is no cap functionality yet in the generator. -- Chris Murphy _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-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/cloud@xxxxxxxxxxxxxxxxxxxxxxx
