On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <johnmh(a)splentity.com> 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(a)gnome.org>
> wrote:
> >
> >
> > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists(a)colorremedies.com>
> > 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