CheckSpace logic doesn't take snapshots into account
Description:
This issue was opened several years ago on the old site: https://bugs.archlinux.org/task/65705
I created an account thinking I would be able to chime in on that thread and express support for having this issue addressed, but creating an account through the new site does not provide access for logging in on the old site. I am not sure if that is the intended behavior or not.
I am hoping it will be helpful to raise this issue again here on the new site, as a way of speaking up to say there is still interest in the community for having Pacman support an alternative CheckSpace
logic if snapshotting is in use.
The gist of the issue is that the CheckSpace
option does not work on systems using Btrfs snapshots. Essentially, what happens is Pacman anticipates the space of a given package being released when the old version is deleted, but the space is not released because the old version is captured in Btrfs snapshots. As a consequence, Pacman will proceed to attempt the update in situations where there is not enough disk space. The update will crash partway through when the available disk space is exhausted, leaving the system in a state that can be tricky to repair.
Personally, I agree with this comment from the thread linked above:
An option to just not count any of the data removed (ie calculate_removed_size() return 0) would prevent this issue.
I am picturing a flag in /etc/pacman.conf
to tell Pacman to assume no space will be freed up during package updates. Users who have a Btrfs snapshotting routine would set that flag. Then, in situations where there is not enough disk space to complete the update, Pacman will exit gracefully during the CheckSpace
routine as intended. At that point the user will have the opportunity to free up disk space with whatever method they think is appropriate, without dealing with the fallout of a crashed update.
Additional info:
- package version: pacman 6.0.2-8
- link to original issue from old site: https://bugs.archlinux.org/task/65705
Steps to reproduce:
The original thread linked above contains a "dummy package" which can be used for recreating this scenario if that is helpful.