I’ve noticed for a while now that each run of zypper dup keeps requiring additional disk space. In this case ANOTHER 1.6GiB.
The following product is going to be upgraded:
openSUSE Tumbleweed 20240206-0 -> 20240216-0
.
.
.
820 packages to upgrade, 27 new, 19 to remove.
Overall download size: 1.36 GiB. Already cached: 0 B. After the operation,
additional 1.6 GiB will be used.
Note: System reboot required.
Continue? [y/n/v/...? shows all options] (y): n
When I installed TW years ago I had my disk setup as 40GB BTRFS for root and 60GB XFS for the home directory.
Back then I had about 25GB free, now it’s ~15GB free.
chris@asus-roc:~>$sudo btrfs filesystem usage -T /
Overall:
Device size: 40.00GiB
Device allocated: 34.53GiB
Device unallocated: 5.47GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 24.01GiB
Free (estimated): 15.14GiB (min: 15.14GiB)
Free (statfs, df): 15.14GiB
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 70.58MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single single single Unallocated Total Slack
-- --------- -------- --------- -------- ----------- -------- -----
1 /dev/sda2 33.00GiB 1.50GiB 32.00MiB 5.47GiB 40.00GiB -
-- --------- -------- --------- -------- ----------- -------- -----
Total 33.00GiB 1.50GiB 32.00MiB 5.47GiB 40.00GiB 0.00B
Used 23.33GiB 698.00MiB 16.00KiB
I have cleaned superfluous user applications off root, deleted --orphaned and --unneeded packages, run dup with --no-recommends and it still keeps chewing up additional disk space. I am seriously considering getting a large NVMe drive with larger partitions to replace the current 120GB SSD as I need to do a lot of housework prior to a dup.
At first I thought it was related to the snapshots on root but I’m not so sure now.
Can anyone explain why this additional disk space keeps getting required?
First off, I’m no zypper and snapshot expert, but can only provide feedback.
I have a couple TW machines, one with a / (btrfs) of 30gb and the other with a / (btrfs) of 40gb. The /home are XFS , each on a dedicated NVME drive. Both running about two years now
I only keep, I think, 3 snapshots.
You should check the current snapshot count (disk consumption). Get rid of any stale ones.
Make sure your system is not keeping old RPMs from past updates.
Something else I discovered about TW … it loves to install so many packages that aren’t really required. I’ve spent over three to four hours diligently REMOVING software that is NOT required.
In hindsight, I should have just reinstalled with now knowledgeable settings - much less time spent.
Zypper logging is so verbose that removing a package can surprisingly easily cause a reduction in available freespace because of the growth of /var/log/zypper.log that the transaction caused. Periodically, logrotate archives zypper.log and starts a new one, so occasionally freespace will take a jump up without a readily apparent cause.
/var/log/journal/ can consume a lot of space if nothing is done to manage it, either manually, or via /etc/systemd/journald.conf.
Drivers and functions are more or less constantly being added to Linux, so most kernel increments require more disk space than their predecessors.
Do you have any reports or documents about this? On an untinkered, but grown system, zypper.log (and its old files) take less than 10MB. So if your zypper.log grows in a way that it takes significant disk space, you have modified/screwed your system…
I don’t have “system”. I have hundreds. The vast majority have / filesystems between 4G and 8G in multiples of 400MiB. All that have been around a while are running with often quite marginal freespace. Thus I’m routinely paying attention to transaction effects on freespace. Another of the reasons for lack of freespace is keeping kernels long past their prime. All I need do is look at /boot/ on nearly any of the TWs to see the kernel growth trend. The file managers I use always show sizes, so on most visits to /var/log/, zypper.log jumps out as either the largest by far, and/or very young and small with (a) recent archive(s) adjoining. The Slowroll on the box I’m currently testing shows:
# ls -gGh zypper*
-rw-r----- 1 125M Feb 19 16:38 zypper.log
-rw-r----- 1 555K Dec 3 02:36 zypper.log-20240122.xz
-rw-r----- 1 1.9M Jan 22 02:41 zypper.log-20240123.xz
#
TW on same box (which has 17 installed kernels), is rather different:
# ls -gGh zypper*
-rw-r----- 1 15M Jan 17 01:54 zypper.log
-rw-r----- 1 517K Oct 14 00:44 zypper.log-20231110.xz
-rw-r----- 1 636K Nov 10 19:23 zypper.log-20231202.xz
#
My primary box, from which I’m typing here, is running 15.5:
# ls -gGh /var/log/zypper*
-rw-r----- 1 374K Feb 18 20:07 /var/log/zypper.log
-rw-r----- 1 3.0M Jan 22 23:55 /var/log/zypper.log-20240123.xz
-rw-r----- 1 3.5M Jan 23 22:57 /var/log/zypper.log-20240124.xz
-rw-r----- 1 497K Jan 24 21:01 /var/log/zypper.log-20240125.xz
-rw-r----- 1 491K Jan 26 16:48 /var/log/zypper.log-20240127.xz
-rw-r----- 1 515K Jan 31 19:56 /var/log/zypper.log-20240201.xz
-rw-r----- 1 1.1M Feb 3 20:37 /var/log/zypper.log-20240204.xz
-rw-r----- 1 506K Feb 4 22:51 /var/log/zypper.log-20240205.xz
-rw-r----- 1 910K Feb 6 22:42 /var/log/zypper.log-20240207.xz
-rw-r----- 1 3.0M Feb 12 10:14 /var/log/zypper.log-20240213.xz
-rw-r----- 1 2.5M Feb 17 22:05 /var/log/zypper.log-20240218.xz
#
I don’t think I quite understand your question, but as far as I know, you have to take the following into account: Both when updating and renewing, the RPM files will be downloaded. The space they will occupy is temporary, because after a while, they will be deleted from the cache. On the other hand, the contents of the RPM files will replace with their contents, partially or completely, the files that were already installed on the system. In other words, in short, the “real” space you will lose will be the difference in size between the sum of the replaced files and the sum of the new files, which is generally not much, unless you have not updated the system for a long time.
In any case, since you are using BTRFS on an SSD, can you tell us the output of the command sudo btrfs fi usage /?
I think you’re barking up the wrong tree. The message is about the total download of packages, which are compressed, and the total these packages will take when unpacked/installed. NOT about the extra space needed on the fs after install.
420 packages to upgrade, 2 new, 2 to remove.
Overall download size: 202.8 MiB. Already cached: 0 B. After the operation, additional 5.8 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
In a general comment, I have in the past run out of space on root just downloading the 1000s of packages prior to installing. This is why I use zypper’s --pkg-cache-dir option.
It would be nice - and wishful thinking - if a dup would instead of downloading ALL packages first it would -
Information for package kernel-source:
--------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : kernel-source
Version : 6.7.5-1.1
Arch : noarch
Vendor : openSUSE
Installed Size : 1.23 GiB
Installed : No
Status : not installed
Source package : kernel-source-6.7.5-1.1.src
Upstream URL : https://www.kernel.org/
Summary : The Linux Kernel Sources
Description :
Linux kernel sources with many fixes and improvements.
Source Timestamp: 2024-02-17 07:45:40 +0000
GIT Revision: a3bab56f26c8c783bb4195c872ddc6b877982fa0
GIT Branch: stable
You probably don’t need the source code for the Linux kernel, so it should be safe to delete. Also run zypper purge-kernels to remove older ones. Other than that what sticks out to me is yabridge, check how much space it uses too.
The following 27 NEW packages are going to be installed:
kernel-default 6.7.5-1.1 x86_64 openSUSE-Tumbleweed-Oss openSUSE
kernel-default-devel 6.7.5-1.1 x86_64 openSUSE-Tumbleweed-Oss openSUSE
kernel-devel 6.7.5-1.1 noarch openSUSE-Tumbleweed-Oss openSUSE
kernel-source 6.7.5-1.1 noarch openSUSE-Tumbleweed-Oss openSUSE
...
927 packages to upgrade, 27 new, 19 to remove.
Overall download size: 1.47 GiB. Already cached: 0 B. After the operation, additional 1.6 GiB will be used.
The kernel-source alone consumes 1.23GiB on disk, kernel-default consumes 240MiB which is already 1.47 out of 1.6 GiB. I am not going to waste time checking the size of other packages for you, but the additional size shown by zypper is entirely reasonable with the packages that are going to be installed.
I do zypper purge-kernels before each dup as well.
yabridge and yabridgectl are not installed. Not sure where you’re seeing this.
chris@asus-roc:~>$zypper if yabridge
Loading repository data...
Reading installed packages...
Information for package yabridge:
---------------------------------
Repository : proaudio
Name : yabridge
Version : 5.0.5-3.20
Arch : x86_64
Vendor : obs://build.opensuse.org/multimedia
Installed Size : 13.6 MiB
Installed : No
Status : not installed
Source package : yabridge-5.0.5-3.20.src
Upstream URL : https://github.com/robbert-vdh/yabridge
Summary : A modern and transparent way to use Windows VST2/VST3 plugins on Linux
Description :
Yet Another way to use Windows VST plugins on Linux. Yabridge seamlessly supports running both 64-bit Windows VST2/VST3 plugins, with optional support for inter-plugin communication through plugin groups. Its modern concurrent
architecture and focus on
transparency allows yabridge to be both fast and highly compatible, while also staying easy to debug and maintain.
chris@asus-roc:~>$zypper if yabridgectl
Loading repository data...
Reading installed packages...
Information for package yabridgectl:
------------------------------------
Repository : proaudio
Name : yabridgectl
Version : 5.0.5-3.20
Arch : x86_64
Vendor : obs://build.opensuse.org/multimedia
Installed Size : 2.6 MiB
Installed : No
Status : not installed
Source package : yabridge-5.0.5-3.20.src
Upstream URL : https://github.com/robbert-vdh/yabridge
Summary : Command line tool for yabridge configuration
Description :
A small, optional utility to help set up and update yabridge for several directories at once.
chris@asus-roc:~>$
