You are not logged in.

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

akobel
Member
From: Saarbrücken, Germany
Registered: 2016-02-12
Posts: 22
Website

Pacman/checkupdates: Net upgrade size / expected disk usage

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?

Offline

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

apg
Developer
Registered: 2012-11-10
Posts: 210

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

What's wrong with CheckSpace?

Offline

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

akobel
Member
From: Saarbrücken, Germany
Registered: 2016-02-12
Posts: 22
Website

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

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...

Offline

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

Awebb
Member
Registered: 2010-05-06
Posts: 6,261

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

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.

Offline

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

akobel
Member
From: Saarbrücken, Germany
Registered: 2016-02-12
Posts: 22
Website

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

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                                                                                                                                                                                                      sad
/dev/mapper/luks--lvm--vg-root   54G   54G   92K 100% /

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

Offline

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

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,346
Website

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

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.

Offline

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

akobel
Member
From: Saarbrücken, Germany
Registered: 2016-02-12
Posts: 22
Website

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

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.

Offline

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

akobel
Member
From: Saarbrücken, Germany
Registered: 2016-02-12
Posts: 22
Website

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

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!

Offline

Board footer

Powered by FluxBB