Pacman/checkupdates: Net upgrade size / expected disk usage

akobel · 2020-02-27 21:53:17

Hi,

on the invocation of pacman -Syu, we are presented with estimates on the total download size (DL), total installed size (INST), and net upgrade size (NET). Pacman cannot have a great picture of my disk landscape, but I happen to - and I know that typically the entire size will be occupied on my root partition. So I want a flag raised if, say, (DL+INST) > free, or (used+DL+INST) > 0.95*total, or something like that. Or perhaps DL is stored on some other partition.

So a way to access DL, INST and NET in an easily parseable form would be great. Preferably in a checkupdates-like manner instead of echo n | pacman -Syu. Anyone knows of an easy way to achieve that?

apg · 2020-02-28 01:45:35

What's wrong with CheckSpace?

akobel · 2020-02-29 09:39:16

Nothing wrong per se, except that it doesn't inhibit upgrades unless DL+NET > free, as far as I understand (and experienced). That's fine for plain file systems without snapshots, but with snap-pac's pre- and post-update-hooks and the like, this is not the right logic. Also, for btrfs, "free space is complicated", to quote the FAQ - I hope that I can make better educated guesses, knowing my setup...

Granted, what I want to achieve is to make an infamous Bad Idea slightly less worse - my goal are automatic nightly updates of a headless (non-mission-critical) virtual server with automatic reboots. I plan to have some sanity checks for the services running before and after the update, as well as notifications to do manual updates in case some predetermined packages are about to be updated; and the snapshots provide me with an easy rollback plan in case an update breaks something. I know that this is generally frowned upon, but I'm willing to accept this risk.

And I did run out of space with manual updates before, despite using CheckSpace, for the reasons outlined above...

Awebb · 2020-02-29 10:57:14

The pacman cache is stored in /var/cache/pacman. You could mount this to another disk. Also, man pacman and look at the --clean switch.

Now open your Window and yell "Sup, Awebb?", chances are I'll hear you.

akobel · 2020-02-29 13:19:26

The pacman cache is not necessarily involved in the equation. FWIW, just assume that all packages are already pre-downloaded via pacman -Syuw. The problem is that DL+NET < free (or even NET < free, since DL=0 in this situation) is just not the right check if snapshots are taken.

To demonstrate, I created a dummy package: Version 1 has 7 GB random contents, to be installed in /huge.rand; version 2 has only 5 GB, also in /huge.rand. Both packages are created locally (and available in another partition).
Thus, for the installation of version 1, DL=0, INST=7GB, and NET=7GB.
For the update to version 2, pacman sees DL=0, INST=5G, and NET=-2GB, and claims everything is fine. But due to the snapshots, I need free > INST for a successful install, not just free > NET - deleting the huge old file doesn't free any space as long as it still remains in the snapshot.

Obviously, that's contrieved. But it would be cool if there was an option like CheckSpace=Snapshot (rather than CheckSpace=Overwrite or similar), where NET := INST is assumed. (I guess that checking for identical files in installed and upgraded version would be too much to ask for, so the safe estimate needs to be that every file changed and is overwritten entirely.) And, perhaps, if a margin could be configured (say, I want to spare 1 GB for post-update hooks like rebuilding initrds or dkms modules, backups via hooks, ...).

akobel@s9 ~/pkg % df -h | grep root
/dev/mapper/luks--lvm--vg-root 54G 43G 11G 80% /

akobel@s9 ~/pkg % sudo pacman -U dummy-1-1-x86_64.pkg.tar.zst
[...]
Packages (1) dummy-1-1

Total Installed Size: 7000.00 MiB

:: Proceed with installation? [Y/n]
[...]
(1/1) checking available disk space [########################################################################################] 100%
:: Running pre-transaction hooks...
(1/1) Performing snapper pre snapshots for the following configurations...
==> root: 5
:: Processing package changes...
(1/1) installing dummy [########################################################################################] 100%
:: Running post-transaction hooks...
(1/2) Performing snapper post snapshots for the following configurations...
==> root: 6
[...]

akobel@s9 ~/pkg % df -h | grep root
/dev/mapper/luks--lvm--vg-root 54G 50G 3.9G 93% /

akobel@s9 ~/pkg % sudo pacman -U dummy-2-1-x86_64.pkg.tar.zst
[...]
Packages (1) dummy-2-1

Total Installed Size: 5000.00 MiB
Net Upgrade Size: -2000.00 MiB
[...]
(1/1) checking available disk space [########################################################################################] 100%
:: Running pre-transaction hooks...
(1/1) Performing snapper pre snapshots for the following configurations...
==> root: 7
:: Processing package changes...
(1/1) upgrading dummy [########################################################################################] 100%
error: could not extract /huge.rand (Write failed)
error: problem occurred while upgrading dummy
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

1 akobel@s9 ~/pkg % df -h | grep root
/dev/mapper/luks--lvm--vg-root 54G 54G 92K 100% /

Last edited by akobel (2020-02-29 13:23:42)

Allan · 2020-03-03 03:51:23

If instead of using snapper as a hook, it was used in a wrapper script around the pacman calls, CheckSpace would work. Not a solution I know...

File a bug asking for the CheckSpace variant to be added, with a description of your setup.

akobel · 2020-03-04 20:04:45

Whoa, that escalated to the right person quickly... Will do.

Besides, it doesn't matter if snapper is called via hooks. Disabling the snap-pac hooks and doing a manual call of snapper create -t pre between the upgrade yields the exact same result.

akobel · 2020-03-04 20:37:58

Done with https://bugs.archlinux.org/task/65705. Thanks - and thanks, and oh so many thanks for what works so extremly well already with pacman!

Arch Linux

#1 2020-02-27 21:53:17

Pacman/checkupdates: Net upgrade size / expected disk usage

#2 2020-02-28 01:45:35

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#3 2020-02-29 09:39:16

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#4 2020-02-29 10:57:14

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#5 2020-02-29 13:19:26

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#6 2020-03-03 03:51:23

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#7 2020-03-04 20:04:45

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

#8 2020-03-04 20:37:58

Re: Pacman/checkupdates: Net upgrade size / expected disk usage

Board footer