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 <lists@xxxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________ 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
