I joined this list because I'm interested in learning more about the specific requirements and features of cloud images.
So I'm wondering what ZRAM adds or what problem ZRAM solves for a cloud image? Thanks On Tue, 2 Jun 2020, 02:38 Chris Murphy <[email protected]> wrote: > Thanks for the early feedback! > > On Mon, Jun 1, 2020 at 7:58 AM Stephen Gallagher <[email protected]> > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] >
_______________________________________________ cloud mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
