Re: How much free space in /var is required for upgrades?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 16, 2022 at 2:55 PM Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:
>
>
>
> On 5/16/22 12:10, Chris Murphy wrote:
> > On Fri, May 13, 2022 at 3:20 PM przemek klosowski via devel
>
> >
> >
> >> Unfortunately, I believe that the current upgrade workflow requires a
> >> root disk three times the total installed package size: each package is
> >> there as the original version, the RPM of the upgrade in the cache
> >> directory, and as a new image before the old one is purged.
> >
> > Yeah I'm not sure it's currently possible to do an atomic update with
> > dnf or rpm, hence rpm-ostree. Or txnupd and btrfs snapshots
> > (essentially dnf and rpm keep doing what they're doing, but create a
> > snapshot of the running system, and update the snapshot out of band,
> > rather than stomping on the currently running OS).
>
> Exactly. This is one of the big value propositions of RPM-OSTree. Silverblue
> (desktop), Fedora CoreOS (Server), or Fedora IoT (Edge/IoT) are options here.
> If your "update" runs out of space for whatever reason then the upgrade is stopped
> and you won't be in a half upgraded state.
>
> As Chris mentioned there are also things like BTRFS snapshots or LVM snapshots,
> etc. that can help you go back in time.
>
> Dusty

If you have the spare time and disk to set up that sort of thing, you
have too much time on your hands and should focus on something useful
to more people, including yourself. It can be fun to outsmart yourself
with resource allocation, it's usually a form of "premature
optimization" that puts your systems at risk when you guess wrong. And
you *will* guess wrong at least once per project. From Donald Knuth:

     “The real problem is that programmers have spent far too much
time worrying about efficiency in the wrong places and at the wrong
times; premature optimization is the root of all evil (or at least
most of it) in programming.”
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux