On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <mcatanzaro@xxxxxxxxx> > > wrote: > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > > > wrote: > > > > > > > That is the plan, otherwise the swap-on-zram device probably never > > > > gets used. And then its overhead, which is small but not zero, is just > > > > a waste. > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap partition, > > > since it has an unacceptable impact on system responsiveness? > > > > > > Default new installations, yes. No disk-based swap partition. > > > > For upgrades, there's no mechanism to remove an existing > > swap-on-drive. And the installer will still permit swap-on-drive being > > added in custom partitioning. Both of these paths results in two swap > > devices. > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > will not get swap-on-zram. And we could also forgo the change being > > applied on upgrades. > > It may be best to respect the user's decision, and not add a zram device on > upgraded systems. This would lead to less unexpected behavior. I'd support > that, for sure :) Contra argument: It also leads to fragmentation of the user base. Most users use a distribution because they trust the decisions. And while it is only a preference, not a policy the Workstation Product Requirements Document says "Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation." There is a balancing act here that should be considered because a large percent of Fedora users upgrade rather than reprovision. It might even be the majority case. -- 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
